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 / 14
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 / 14
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 / 14
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 / 14
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.'
6 / 14
Sarah, a junior developer, sent this Slack message to the team: 'Just finished implementing the new user profile update. I've added some client-side validation to ensure users enter valid email addresses and names. I'm using a regular expression to enforce the format – it should prevent invalid data from being saved.' Which OWASP Top 10 vulnerability is Sarah *most* likely addressing with this approach?
Sarah's use of a regular expression to validate user input directly tackles SQL injection (A03). While validation is good practice, relying solely on client-side validation without server-side checks leaves the application vulnerable if an attacker can bypass or manipulate the client-side code. The other options relate to different vulnerabilities – broken access control, insecure design and misconfiguration.
7 / 14
Mark, a senior developer, is writing a pull request description for a new feature: 'This change introduces a new API endpoint to retrieve product details. The API uses JSON as the response format and includes pagination to handle large datasets. The server-side code carefully sanitizes all input to prevent any potential vulnerabilities.' Which OWASP Top 10 vulnerability is Mark *most* focused on mitigating?
Mark's emphasis on sanitizing input is a direct response to injection vulnerabilities (A02), particularly SQL injection or command injection. While proper authentication and secure components are important, the core concern here is preventing attackers from injecting malicious code through user-supplied data. The other options address different security concerns like access control, vulnerable software, or authentication problems.
8 / 14
Emily, a security engineer, is reviewing a developer's code and comments this: 'The application dynamically generates HTML content using user input. If an attacker can control the input, they could inject malicious JavaScript code into the page—resulting in XSS attacks. The correct defense is to properly encode or escape any output before rendering it.' Which OWASP Top 10 vulnerability does Emily's comment *primarily* relate to?
Emily's statement directly addresses Cross-Site Scripting (XSS) (A02). XSS vulnerabilities occur when untrusted data is rendered within an HTML page without proper encoding. This allows attackers to inject malicious scripts that execute in the user's browser. The other options relate to different security issues like broken access control, misconfiguration, or insecure logging.
9 / 14
Lisa, a developer, is discussing a security issue with her team. She says: 'Our application uses a third-party library for handling image uploads. The library doesn't properly validate the file type or size before saving it to our server. An attacker could upload a malicious PHP script disguised as an image and execute it on the server.' Which OWASP Top 10 vulnerability is Lisa describing?
Lisa's explanation focuses on File Inclusion vulnerabilities (A09), which often manifest as code injection. By allowing attackers to upload and execute arbitrary files, they can inject malicious code into the server environment. The other options relate to different types of vulnerabilities – broken access control, injection attacks or insecure deserialization.
10 / 14
David, a team lead, is responding to a Slack message from Ben regarding a recent PR. David writes: 'Okay, I see you're using string concatenation to build the SQL query for the product search. While it works now, this opens us up to potential SQL injection vulnerabilities. It's crucial to use parameterized queries or prepared statements instead to protect against malicious input.' Which of the following best describes David's concern?
David is highlighting a significant security risk: SQL injection. String concatenation directly into queries allows an attacker to inject malicious SQL code. Parameterized queries or prepared statements isolate the query structure from user input, preventing this vulnerability. Ben's approach represents a fundamental misunderstanding of secure coding practices.
11 / 14
During a standup meeting, Maria explains her work on the new user registration feature. She states: 'I've implemented client-side validation to ensure users enter valid email addresses and names before submitting the form. This helps prevent invalid data from reaching the server.' Which OWASP Top 10 category does Maria's action primarily address?
Maria's implementation of client-side validation directly addresses OWASP A03: Improper Input Validation. This category covers failing to properly validate user input before processing it – in this case, preventing invalid data from reaching the server. While authentication and outdated components are relevant, Maria's specific action falls squarely under input validation.
12 / 14
Reviewer Alex is examining a PR that adds a new feature for generating previews of documents. The code includes the following snippet: 'String $previewContent is directly inserted into the HTML without any sanitization or escaping.' What type of vulnerability does this represent?
This scenario directly demonstrates a Cross-Site Scripting (XSS) vulnerability. By injecting arbitrary HTML or JavaScript code into the preview content and rendering it without proper sanitization, an attacker can execute malicious scripts in the user's browser. The lack of output encoding makes the application susceptible to XSS attacks.
13 / 14
During a code review, Sarah comments on a developer's implementation: 'I'm concerned that we are accepting user input directly into the `user_id` parameter of our API endpoint. This could potentially lead to an attacker manipulating the ID and gaining unauthorized access to sensitive data.' Which OWASP Top 10 category does Sarah's comment relate to?
Sarah's comment directly addresses OWASP A02: Sensitive Data Exposure. By accepting user-provided input as an ID without proper validation or authorization checks, the application exposes a vulnerability that could be exploited to access unauthorized data. The direct manipulation of the `user_id` parameter is the core issue.
14 / 14
You are reviewing a PR that implements a new feature to allow users to upload images. The code doesn't perform any checks on the file type or size before saving it to storage. What is the primary security risk associated with this design?
The primary security risk is Unrestricted File Upload. Without file type and size validation, an attacker can upload malicious files – such as shell scripts or executable code – which could then be executed on the server. This allows for Remote Code Execution vulnerabilities.
What does the "OWASP Top 10 Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to owasp top 10 vocabulary through 14 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 14 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.