az0x7/vulnerability-checklist

This repository is a documentation-only security checklist library, not an executable application. Its “architecture” is a curated set of Markdown notes grouped by vulnerability class, with a few supporting PDFs, text payloads, and YAML templates for framework-specific testing.

1. Core structure

The repo is organized as one top-level folder per attack surface or vulnerability family. Each folder contains a single primary document, usually a Markdown checklist, that captures probing ideas, bypass techniques, and validation steps for that topic.

2. Main content domains

The strongest architectural split is between identity/access-control topics and general web-exploitation topics. Identity-related areas include Authentication, API Authentication, API Authorization, 2FA Bypass, Account Takeover, Reset Password, Register Vulnerability, Cookie Attack, 403 Bypass, IDOR, and Admin Panel. These are the repo’s access and privilege boundaries.

3. Application-layer vulnerability cluster

A second major subsystem covers classic web application flaws: CSRF, XSS/RXSS, Mass Assignment, Business Logic, JSON Attack, File Upload, SQL Injection, RCE, Rate Limit bypass, and EXIF geolocation leakage. These documents focus on request/response manipulation and server-side trust failures.

4. Framework-specific playbooks

Two folders are dedicated to framework-oriented checklisting: Hacking Django and Hacking Symfony. These are more specialized than the generic web-checklists and imply framework-specific attack paths, misconfigurations, and templates.

5. Misconfiguration and platform exposure

AEM misconfiguration is a separate category, indicating the repo also tracks platform-level exposure rather than only application bugs. This sits alongside the framework-specific content as a “technology target” layer.

6. Supporting artifact types

Most content is Markdown, but there are also PDFs in File Upload, a SQL payload text file in Sql injection, and YAML templates in Hacking Django and Hacking Symfony. These auxiliary artifacts suggest the repo is meant as a practical field guide, with reusable payloads and template-based testing references.

7. Knowledge flow through the repo

The effective data flow is from broad vulnerability category to specific checklist. A user likely starts at README.md, then follows the linked topic folder, then uses the local artifact files inside that folder as reference material for testing or triage.

8. README as the index layer

README.md acts as the repository index and navigation boundary. It lists the major checklists, links them to their folders, and establishes the canonical set of topics the repo considers in scope.

9. Cross-cutting themes

Several documents overlap conceptually: authentication, session/cookie handling, authorization, and account takeover are adjacent; likewise rate limiting, reset password, 2FA bypass, and register flows all belong to account lifecycle abuse. This overlap is important when drawing the architecture because these are not isolated silos.

10. Repository boundary

There is no build pipeline, service runtime, database, or application backend in this repo. The only “runtime” concern is the human analyst using the docs as a playbook. So the architecture diagram should show a documentation hub with topic folders, not a software system with deployable components.

11. Practical diagramming model

A clear architecture diagram would place README.md at the center as the entry point, branch into major security domains, then fan out into the individual checklist files and supporting payload/template artifacts. The key boundary is between index/navigation, domain checklists, and reusable supporting files.