## https://sploitus.com/exploit?id=D96CCA0A-A61A-5D94-A129-30B502324170
# Common Web Application Bug Classes Cheatsheet
A defensive reference for the most frequently reported classes of web application vulnerabilities, structured for quick lookup during code review, security assessments, and incident triage. Each section outlines what the bug is, how it typically manifests, a small example of the shape of the payload used in testing, and the defense pattern that neutralizes the class.
---
## Overview
The Open Web Application Security Project (OWASP) has published Top 10 lists of application-security risks since 2003, and the pattern of what breaks in web applications is remarkably stable across those revisions. Injection, broken authentication, sensitive-data exposure, and access-control failures continue to represent the majority of confirmed vulnerabilities disclosed each year. This cheatsheet consolidates the most common classes into a single reference, oriented toward defenders: application developers who want to internalize the shape of these bugs, code reviewers looking for triage patterns, and incident responders who need to identify the vulnerability class behind an alert quickly.
Every technique described here is documented publicly in the OWASP cheat-sheet series, MITRE's CWE catalog, and the standard training curricula used across the industry. The intent is education and hardening, not to enable exploitation. Where sample payloads are shown, they are the well-known canonical strings used in test suites and CTF challenges. Effective defense requires understanding what the input side of a vulnerability looks like, so we do not hide the shape of the payloads, but we place the emphasis on the mitigation.
## SQL Injection
SQL injection (SQLi) occurs when untrusted input is concatenated into a SQL statement without parameterization. The classic signal is a string-format style construction such as `"SELECT * FROM users WHERE name = '" + name + "'"`. An attacker who controls `name` can terminate the string literal and append arbitrary SQL.
Canonical test strings include:
```
' OR '1'='1
' UNION SELECT NULL, version(), NULL--
'; WAITFOR DELAY '0:0:5'--
```
The first is a boolean-based check used to detect that user input is being interpolated into a query. The second attempts a UNION-based read. The third is a time-based blind SQLi against SQL Server. Blind variants exist for every mainstream database and are typically automated by tools like `sqlmap` after the initial detection.
**Defense**: Use parameterized queries or prepared statements exclusively. Every mainstream database driver (JDBC, psycopg, node-postgres, `mysqli`, `PDO`, `sqlx`) supports parameter binding. ORMs typically parameterize automatically, but raw SQL escape hatches must still be reviewed. Input validation is a defense-in-depth measure, not a substitute for parameterization. Dynamic identifiers such as table or column names should be validated against an explicit allow-list, since parameter binding does not cover them.
## Cross-Site Scripting (XSS)
XSS arises when attacker-controlled input is rendered into an HTML context without proper encoding. It has three canonical variants:
| Variant | Where the payload lives | Trigger |
|---------|-------------------------|---------|
| Reflected | In a request parameter, echoed into the response | Victim clicks a crafted link |
| Stored | In the application database | Victim views a page that renders the stored value |
| DOM-based | In client-side JavaScript that unsafely manipulates the DOM | Victim loads a page that reads and uses attacker-controlled input |
Well-known probe strings:
```html
alert(1)
">
javascript:alert(1)
```
**Defense**: Apply context-appropriate output encoding: HTML entity encoding when writing into element text, attribute encoding when writing into attribute values, JavaScript-string encoding when writing into script blocks. Modern templating engines (Jinja2, React JSX, Handlebars with escape enabled) do this by default. Content Security Policy adds a second layer that limits the impact of any escape that slips through. Avoid `innerHTML`, `document.write`, and `eval` on user-controlled data. For rich text where HTML must be preserved, use a maintained sanitizer such as DOMPurify with the default policy.
## Server-Side Request Forgery (SSRF)
SSRF occurs when an application fetches a URL that the attacker can influence. The canonical test targets are cloud metadata services and internal address ranges:
```
http://169.254.169.254/latest/meta-data/
http://metadata.google.internal/computeMetadata/v1/
http://[::1]/
http://localhost:8080/admin
```
An SSRF may allow the attacker to reach internal services, exfiltrate cloud instance credentials, or scan private networks. On AWS the classic Capital One breach in 2019 was rooted in an SSRF that reached the IMDSv1 endpoint and retrieved instance-role credentials.
**Defense**: Restrict outbound URLs to an allow-list of hostnames when the application architecture permits it. When arbitrary user URLs must be fetched (link previews, webhooks), resolve the hostname first, reject any resolution to a private IP range (RFC 1918, loopback, link-local, IPv6 equivalents), enforce a strict timeout, and disable HTTP redirects unless each hop is re-validated. On AWS, prefer IMDSv2, which requires a token and mitigates the classic metadata-service SSRF pattern.
## XML External Entity (XXE)
XXE affects XML parsers configured to resolve external entities. A minimal payload declares an entity that reads a local file:
```xml
]>
&xxe;
```
The impact ranges from arbitrary file read on the server, to SSRF via the entity URL, to denial of service via billion-laughs style exponential expansion.
**Defense**: Disable external entity and DTD processing in every XML parser used by the application. In Java, set `XMLConstants.FEATURE_SECURE_PROCESSING` and disable the `disallow-doctype-decl` feature. In Python, use `defusedxml` instead of `lxml`'s default parser. In .NET, set `XmlReaderSettings.DtdProcessing = DtdProcessing.Prohibit`. Where XML is not required, prefer JSON, which does not support external entities.
## Insecure Direct Object References (IDOR)
IDOR is an access-control failure in which the application exposes a reference to an internal object (typically a database primary key) and does not validate that the caller has permission to access it. A URL like `GET /api/invoices/48219` becomes vulnerable when incrementing the ID returns another user's invoice.
There is no payload to speak of; the "test" is simply substituting IDs. IDOR is best detected in code review by looking for handlers that fetch an object by an ID from the request and do not check ownership before responding. Automated scanners struggle with IDOR because the check requires semantic understanding of what "authorized" means in the application's data model.
**Defense**: Every handler that operates on a persisted object must include an authorization check. Prefer opaque identifiers (UUIDs, HMAC-signed references) over sequential integers when the identifier appears in URLs. Frameworks such as `django-guardian`, `CanCanCan`, and `Casbin` provide policy layers. Whichever approach the team uses, the rule is that the identity of the caller is a required input to every object-fetch.
## Path Traversal
Path traversal (also called directory traversal) occurs when user-supplied input is used to construct a file-system path without normalization. Canonical probes include:
```
../../../../etc/passwd
..%2f..%2f..%2fetc%2fpasswd
....//....//etc/passwd
%2e%2e%2f%2e%2e%2fetc%2fpasswd
```
**Defense**: Resolve the requested path against a fixed base directory, then verify the resolved absolute path is still under that base directory before opening the file. In Python, `os.path.commonpath([base, resolved]) == base`; in Node, compare `path.resolve(base, user)` against `base` with a `startsWith` check that includes the trailing separator. Never trust that a decode-then-check ordering will be safe, since decoders vary and platform-specific quirks (Windows short filenames, UTF-8 canonicalization) frequently defeat naive filters.
## Insecure Deserialization
Deserialization vulnerabilities allow an attacker to influence the reconstruction of application objects from untrusted input. The classic case is Java's `ObjectInputStream.readObject` against attacker-controlled bytes, which can trigger arbitrary code execution through gadget chains built from library classes on the classpath. `pickle` in Python, `Marshal.load` in Ruby, and `unserialize` in PHP have equivalent issues.
There is no single canonical payload — every gadget chain is language- and library-specific. The `ysoserial` project maintains public gadget generators for Java as a research tool; equivalents exist for .NET (`ysoserial.net`), Python (`peas`), and PHP (`PHPGGC`).
**Defense**: Do not deserialize untrusted data with format-native deserializers. Prefer schema-driven formats such as JSON with a strict schema, or Protocol Buffers, and reconstruct objects from validated fields. If the language deserializer must be used, sign the serialized blob with a message authentication code and verify the signature before deserializing. Even with signing, treat the operation as a code-execution primitive.
## Command Injection
Command injection occurs when input is concatenated into a shell command. Payloads terminate the intended command and start a new one:
```
; id
| id
`id`
$(id)
&& ping -c 1 example.com
```
**Defense**: Never build shell commands by string concatenation. Use APIs that accept an argument array and invoke the target binary directly (`execve`, `subprocess.run([...], shell=False)`, `child_process.execFile`, `exec.Command` in Go). If a shell must be used, apply strict input allow-lists. Never pass user-controlled data as flags either, since flag injection into tools like `curl`, `git`, or `find` can be as damaging as shell metacharacter injection.
## Open Redirect and SSRF-Adjacent Issues
Open redirects are relatively low severity on their own but frequently chain into phishing and OAuth code-theft attacks. Validate redirect targets against an explicit allow-list of internal paths or hosts rather than accepting arbitrary URLs. Related issues include HTTP host-header injection, HTTP request smuggling, and cache poisoning; all reward the same defensive posture of treating every URL, header, and body field as untrusted until parsed against a schema.
## Server-Side Template Injection (SSTI)
SSTI arises when user input is concatenated into a template string that is then rendered. In engines like Jinja2, Twig, and Freemarker, this can escalate to remote code execution because the template language exposes access to the runtime.
**Defense**: Never build templates from user input. Templates are code; render them with attacker-controlled data as parameters, never as template source.
## Tooling
- **Burp Suite** and **OWASP ZAP** — intercepting web proxies used for manual and semi-automated testing
- **sqlmap** — automated SQLi detection and exploitation, useful for demonstrating impact in authorized engagements
- **Semgrep** and **CodeQL** — pattern-based static analyzers with mature rule packs for the classes above
- **Trivy**, **Snyk**, and **npm audit** / **pip-audit** — dependency scanners that catch known-vulnerable versions of parsers, serializers, and templating engines
- **git-secrets** and **truffleHog** — pre-commit and repository scanners for accidental credential exposure
- **DOMPurify** — client-side HTML sanitizer for rich-text scenarios
- **defusedxml** — safer XML parsing wrappers for Python
## Examples
See `examples/` for sample files:
- `payloads.txt` — curated collection of canonical test strings for each bug class
- `secure-config.md` — defense patterns and configuration references
## References
- OWASP Top 10: https://owasp.org/www-project-top-ten/
- OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org
- MITRE CWE Top 25: https://cwe.mitre.org/top25/
- OWASP SSRF Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
- OWASP XXE Prevention: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
- OWASP Deserialization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html
- Semgrep rules: https://semgrep.dev/r
- ysoserial: https://github.com/frohoff/ysoserial
- PortSwigger Web Security Academy: https://portswigger.net/web-security
---
*For educational and defensive research purposes only. Do not misuse.*