5 exercises — Practice OWASP Top 10 security vocabulary in English: the A01-A10 category system, injection attacks, XSS, SSRF, and broken access control.
A security engineer briefs the development team before a penetration test: "We follow the OWASP Top 10 — it's the industry-standard list of the most critical web application security risks. The number-one risk in the 2021 edition is A01: Broken Access Control. This means the application fails to enforce what users are allowed to do. A user can escalate their privileges, access another user's data, or view admin pages by simply manipulating a URL parameter or an API request. It's not about hacking encryption — it's about the app trusting user input to determine access." What does Broken Access Control (A01) mean in the OWASP Top 10?
Broken Access Control (A01): the most prevalent web application vulnerability class. The application makes authorization decisions based on user-controlled input without properly verifying permissions server-side. Common manifestations: IDOR (Insecure Direct Object Reference) — changing /api/orders/1234 to /api/orders/1235 reveals another user's order. Privilege escalation — a regular user accesses admin endpoints. Missing function-level access control — admin pages not linked in the UI but accessible via direct URL. CORS misconfiguration — trusting arbitrary origins allows cross-site API calls. Mitigation: enforce access control server-side on every request, default to deny, use least privilege, log access control failures. OWASP Top 10 vocabulary: A02 Cryptographic Failures: sensitive data exposed due to weak or missing encryption (formerly "Sensitive Data Exposure"). A03 Injection: attacker-controlled data interpreted as commands (SQL, OS commands, LDAP queries). A04 Insecure Design: architectural flaws, not just implementation bugs — missing threat modeling. A05 Security Misconfiguration: default credentials, open cloud storage, verbose error messages, unnecessary features enabled. In conversation: 'Every API endpoint that handles user data needs an explicit authorization check. Never assume that because a URL isn't in the menu, attackers won't find it.'
2 / 5
A developer presents a code review finding: "I found a critical vulnerability in the search feature. The user's input is concatenated directly into the SQL query string: SELECT * FROM products WHERE name = '" + userInput + "'". An attacker can type ' OR '1'='1 and retrieve all rows, or use '; DROP TABLE products; -- to destroy data. This is OWASP A03 — one of the oldest and most dangerous vulnerability classes. The fix is parameterized queries or prepared statements, where user input is always treated as data, never as SQL syntax." What is SQL injection and why does it occur?
SQL injection (SQLi): the classic injection vulnerability. Root cause: mixing code and data — the query template and the user's input are concatenated into a single string, so the database parser cannot distinguish between them. Attack types: In-band SQLi: results returned directly in the response (UNION-based to extract data, error-based for schema info). Blind SQLi: no direct output, but attacker infers data from boolean responses or timing delays. Out-of-band SQLi: data exfiltrated via DNS or HTTP requests triggered by the database. Defences: Parameterized queries / prepared statements: the query structure is fixed; user input is passed separately as typed parameters. The database never interprets input as SQL. Stored procedures: if parameterized internally, also safe. ORMs: usually parameterize automatically — but raw query escape hatches (like Django's extra()) still require care. Input validation: defence-in-depth, not a primary control. OWASP A03 covers the broader Injection category: OS command injection, LDAP injection, XPath injection, template injection (SSTI). In conversation: 'Any time you see string concatenation near a database call, treat it as a critical finding. Parameterized queries have existed for decades — there is no excuse for SQLi in new code.'
3 / 5
A security analyst explains a reported bug to the team: "A user found they could inject a script tag into their display name. When any other user views the profile page, the script runs in their browser — it can steal session cookies, redirect to phishing pages, or silently make API calls on their behalf. This is stored XSS. The dangerous part: the attacker doesn't need to trick the victim into clicking a special link. The malicious script is already in the database, waiting for any visitor. Content Security Policy and proper output encoding are the mitigations." What is the difference between stored XSS and reflected XSS?
XSS (Cross-Site Scripting): attacker-controlled scripts execute in a victim's browser within the application's origin, inheriting its cookies, storage, and DOM access. Three types: Stored (persistent) XSS: payload saved in the backend (database, file, log) and rendered for other users. Highest impact — no interaction needed beyond normal browsing. Reflected (non-persistent) XSS: payload in the request URL or POST body is immediately reflected in the response. Victim must click a crafted link or submit a form. DOM-based XSS: payload never reaches the server; client-side JavaScript reads from an unsafe source (like location.hash) and writes to an unsafe sink (like innerHTML). Defences: Output encoding: HTML-encode user-controlled values inserted into HTML, JavaScript-encode values in JS contexts. Content Security Policy (CSP): HTTP header restricting which scripts may execute — prevents inline scripts and untrusted sources. HttpOnly cookies: prevents JavaScript from reading session cookies even if XSS executes. Trusted Types API: modern browser API requiring safe DOM manipulation. In conversation: 'When you use innerHTML with user data, you're one forgotten encoding call away from XSS. Prefer textContent, or use a sanitization library for rich content.'
4 / 5
A cloud security engineer describes a critical finding during an AWS security review: "The application fetches a URL that the user provides — for example, to generate a preview of a web page. But the server doesn't validate what URL it fetches. An attacker sent the URL http://169.254.169.254/latest/meta-data/iam/security-credentials/. That's the AWS instance metadata service. The server fetched it and returned the IAM role credentials to the attacker. They now have AWS access keys. This is SSRF — Server-Side Request Forgery — and it's number ten on the OWASP list." What is SSRF and what makes it dangerous in cloud environments?
SSRF (Server-Side Request Forgery): the server is induced to make outbound HTTP requests to destinations the attacker controls. The request originates from the server's network context — which has access to internal services, cloud metadata endpoints, and private IP ranges unreachable by the attacker directly. Why devastating in cloud: AWS IMDSv1: http://169.254.169.254/ returns IAM role temporary credentials with no authentication (IMDSv2 requires a PUT token first — enforce it). GCP metadata API: http://metadata.google.internal/ exposes service account tokens. Azure IMDS: http://169.254.169.254/metadata/instance. Beyond metadata: attackers can scan internal networks, access internal APIs (Kubernetes API server, Redis, Elasticsearch), interact with internal admin interfaces, and exfiltrate data to attacker-controlled servers. Defences: Allowlist: only permit fetching specific, pre-approved external domains. Block private IP ranges: validate resolved IPs against RFC 1918 (10.x, 172.16-31.x, 192.168.x) and link-local (169.254.x.x). IMDSv2: requires session-oriented token flow, blocking simple SSRF. Separate fetch service: run URL fetching in a sandboxed environment with no access to internal networks. In conversation: 'Any feature that fetches a user-supplied URL is an SSRF candidate. The fix isn't just validation — it's defense-in-depth: validate, resolve, re-validate the IP, and restrict outbound network access.'
5 / 5
A senior developer explains OWASP A06 during a dependency audit: "We found that our application uses a version of Log4j with the Log4Shell vulnerability — CVE-2021-44228. This falls under OWASP A06: Vulnerable and Outdated Components. The risk is that we're running known-vulnerable third-party code in production. Attackers actively scan for it. The remediation is straightforward: upgrade. But finding it requires having a complete Software Bill of Materials — an SBOM — so you know every dependency and its version, including transitive ones. If you don't know what you're running, you can't protect it." What is an SBOM and why is it important for OWASP A06?
SBOM (Software Bill of Materials): a formal, machine-readable inventory of all software components in a product — direct dependencies, transitive dependencies (dependencies of dependencies), versions, and licenses. Formats: CycloneDX, SPDX. Why critical for OWASP A06: Transitive dependencies: your code may not directly import Log4j, but a library you use might. Without an SBOM, you don't know. When Log4Shell was disclosed, organizations with SBOMs could check within minutes; others took days of manual audit. CVE matching: tools like Dependabot, Snyk, OWASP Dependency-Check, and Grype match your SBOM against the National Vulnerability Database (NVD). Supply chain security: OWASP A08 (Software and Data Integrity Failures) covers broader supply chain — build pipeline integrity, package signing, and avoiding malicious packages. OWASP vocabulary: CVE: Common Vulnerabilities and Exposures — standardized vulnerability identifier. CVSS score: 0-10 severity rating. Zero-day: vulnerability with no patch yet. Patch management: systematic process of applying security updates. SCA (Software Composition Analysis): automated scanning of dependencies for known vulnerabilities. In conversation: 'Generate your SBOM at build time and scan it automatically in CI. If a critical CVE drops at 3am, you want a Slack alert, not a Friday morning audit.'