A practical field manual for authorized web application security work: define scope, map assets and features, form hypotheses, validate safely, capture evidence, report clearly, and support remediation.
- A methodology-first guide for authorized web, API, cloud-adjacent, and AI/LLM application security testing.
- A curated navigation layer over standards, tools, payload references, reports, labs, and imported research notes.
- A field workflow for turning observations into validated findings and fixable remediation.
- Not permission to test third-party systems.
- Not a payload dump.
- Not a scanner recipe book.
- Not a collection of guaranteed exploits.
- Not a replacement for written authorization, program rules, or legal review.
Use the workflow pages first. Some imported resource, payload, and tool pages are still being cleaned and may contain placeholders, duplicate links, lab hostnames, raw snippets, or generated extraction blocks.
High-confidence entry points:
Raw databases and generated resource pages are useful for search and triage. Do not treat them as reviewed instructions until they pass the content quality checklist.
Get oriented quickly Quickstart gives the shortest safe path from scope to a test hypothesis.
Run a structured assessment Playbooks is the operational spine: workflows, stop conditions, expected output, and evidence.
Choose a vulnerability family Bug Classes helps you move from feature signal to testable hypothesis.
Pick a tool by job Tools explains passive/active behavior, inputs, output, and validation rules.
Use payload references safely Payloads keeps test inputs tied to context, sink, parser, proof, and stop condition.
Write a finding Reports turns behavior into evidence, impact, remediation, and retest steps.
Browse curated references Resources and Top 25 references are for learning and verification after the workflow is clear.
Understand page trust
Documentation Status And Trust Model explains reviewed, needs_triage, generated, and archival.
authorization
-> scope
-> assets
-> features and trust boundaries
-> signals
-> hypothesis
-> safe validation
-> evidence
-> report
-> remediation
-> retest
Every test should have:
- written authorization
- an affected asset
- a feature or trust boundary
- a bug-class hypothesis
- a safe validation plan
- minimal reproducible evidence
- a remediation path
- Confirm scope and stop conditions in Quickstart.
- Pick a workflow from Playbooks.
- Build an asset and feature map.
- Choose a bug-class hypothesis from Bug Classes.
- Choose tools only after the job is clear: Tools.
- Use payloads only with context: Payloads.
- Capture evidence and write the finding: Reports.
- Stop when impact is proven.
The playbooks are the spine of the manual.
- Recon to first bug
- Black-box web assessment
- API assessment
- OSINT and dorking review
- Cloud exposure review
- Source-assisted review
- AI/LLM application review
- Reporting and evidence
Start with the feature and trust boundary, not a payload list.
- Auth boundary, roles, object ownership, or tenant isolation: Access Control, Authentication, API Security
- Browser-executed input, DOM behavior, or user-controlled rendering: Client-Side
- URL fetcher, webhook, importer, previewer, parser, or metadata access: Server-Side
- Upload, archive, document conversion, SVG/XML/PDF parsing, or stored file handling: Files and Parsers
- Query, filter, search, reporting, or database-backed input: Injection
- Proxy/front-end/back-end HTTP framing inconsistency: Server-Side
- AI feature with retrieval, tools, memory, agents, or generated output sinks: AI and LLM Application Security, Prompt Injection
A finding is not ready until it has:
- affected asset and scope
- affected role, account, object, tenant, or data boundary
- exact request and response where applicable
- timestamp and environment
- expected behavior versus actual behavior
- impact without overclaiming
- minimal proof without unnecessary data access
- remediation guidance
Use Reports before opening a finding.
Tools support a hypothesis; they do not replace one.
Do not run payload-heavy automation until scope, rate limits, and the relevant bug class are clear.
Start with official standards, labs, and original documentation:
- OWASP WSTG
- OWASP ASVS
- OWASP Cheat Sheet Series
- OWASP API Security Top 10
- PortSwigger Web Security Academy
- MDN Web Security
- Burp Suite Documentation
- OWASP Top 10 for LLM Applications
See the curated Top 25 Web AppSec Links.
The repository includes imported datasets and generated pages. Use them for search and source discovery, not blind execution.
If a page contains placeholders, lab-only hosts, duplicate links, raw commands without purpose/input/output/safety notes, or Tier/Value/Source/Context extraction blocks, treat it as triage material.
Read Documentation Status And Trust Model before relying on pages marked needs_triage, generated, or archival.
- Test only systems you own, lab systems, CTF targets, or assets where you have explicit written authorization.
- Read program scope, exclusions, rate limits, and safe-harbor terms before running tools.
- Prefer passive discovery and manual validation before automation.
- Stop when impact is proven. Do not dump data, persist access, or create unnecessary harm.
- Treat secrets, tokens, PII, internal URLs, prompts, and retrieved AI context as sensitive evidence.
Do not use this manual for unauthorized testing, opportunistic target hunting, credential use, data extraction, persistence, destructive proof, or bypassing program rules.
Good additions are welcome if they are curated, safe, and useful in the field.