5 exercises — input validation, sanitisation, SAST/DAST, and secure code review vocabulary for developers and security engineers. Advanced
0 / 14 completed
1 / 14
A Java code review finds this line:
String query = "SELECT * FROM users WHERE email = '" + email + "'";
The review comment reads: "This is vulnerable to SQL injection — use parameterised queries."
What does a parameterised query (prepared statement) mean?
Parameterised queries (prepared statements) separate SQL structure from user data — user input is always a parameter, never part of the SQL text.
Vulnerable (string concatenation):
String query = "SELECT * FROM users WHERE email = '" + email + "'";
// If email = "' OR '1'='1", the query becomes:
// SELECT * FROM users WHERE email = '' OR '1'='1'
// → returns ALL users
Safe (parameterised query):
PreparedStatement stmt = conn.prepareStatement(
"SELECT * FROM users WHERE email = ?");
stmt.setString(1, email);
// User input goes into the '?' slot as a typed string value
// It is NEVER parsed as SQL — injection is structurally impossible
Key vocabulary:
Input binding — attaching user data to a parameter slot in the query template
Query template — the SQL structure with ? placeholders, compiled separately from the data
SQL structure separated from data — the core principle that makes injection impossible
String concatenation / interpolation — the dangerous pattern that enables SQL injection
2 / 14
A SAST tool reports a high severity finding in the CI pipeline's code scan.
What does SAST stand for, and how does it differ from DAST?
SAST = white-box, analyses code at rest. DAST = black-box, attacks a running application. Both are needed — they find different vulnerability types.
Testing type
Approach
Finds
Misses
SAST
Analyses source/bytecode statically
Injection patterns, hardcoded secrets, insecure function calls
Runtime misconfigurations, logic flaws, auth bypass in running state
DAST
Attacks a running application
Injection, auth bypass, business logic flaws, runtime misconfigs
Code-level issues invisible at runtime (e.g., unused insecure function)
Requires agent deployment; coverage depends on test execution
RASP
Runtime protection embedded in production app
Blocks attacks in real time; detects novel exploits
Performance overhead; not a substitute for shift-left testing
Key vocabulary: "false positive rate", "shift-left security", "security gate in CI", "SCA (Software Composition Analysis)" — scanning dependencies for known CVEs.
3 / 14
A code review comment reads: "This function doesn't sanitise the filename before passing it to the file system — path traversal vulnerability."
What is a path traversal attack?
Path traversal = attacker uses ../../ sequences to escape the intended directory and reach arbitrary files on the server.
Example attack:
GET /download?file=../../../../etc/passwd
// If the application does: readFile('/uploads/' + filename)
// The resolved path becomes: /uploads/../../../../etc/passwd → /etc/passwd
Secure mitigation:
// Java example — canonicalise and validate the path stays within bounds
String basePath = "/var/app/uploads/";
File requested = new File(basePath + filename).getCanonicalFile();
if (!requested.getPath().startsWith(basePath)) {
throw new SecurityException("Path traversal detected");
}
Mitigation technique
How it helps
Canonicalisation
Resolve .. and symlinks to the absolute real path before validation
Allowlist approach
Only accept filenames matching an explicit safe pattern (e.g., alphanumeric + extension)
Path prefix check
After canonicalisation, confirm the resolved path starts with the expected base directory
Blocklist (weak)
Strip ../ — attackers can bypass with URL encoding (%2e%2e%2f) or double encoding
4 / 14
A security reviewer flags: "The API has broken object-level authorisation at the /api/documents/{id} endpoint."
Which code review finding should the reviewer document?
BOLA/IDOR = the endpoint fetches a resource by ID without verifying that the requester owns or is permitted to access it. The fix is an ownership/permission check — not opaque IDs.
Finding
Is it BOLA?
Why / why not
No ownership check before returning document
✓ Yes — root cause
Any authenticated user can request any document ID — horizontal privilege escalation
Sequential integer IDs instead of UUIDs
Related but not the root cause
UUIDs make enumeration harder but do NOT fix BOLA — guessability ≠ authorisation
No rate limiting on ID parameter
Related but not the root cause
Rate limiting slows enumeration but doesn't prevent a single unauthorised fetch
Correct code review comment:
// Add ownership check before returning the resource:
const document = await db.documents.findById(id);
if (document.ownerId !== currentUser.id) {
throw new ForbiddenError("Access denied");
}
When is a security backlog acceptable? Non-critical technical debt items (e.g., rotating a non-sensitive internal key, upgrading a library with no known exploit) may reasonably be deferred. Design-level vulnerabilities with active exploitation potential should not be deferred — they compound over time as more dependent code is built on the insecure foundation.
Key vocabulary: "SDLC security gates", "threat model review in design phase", "security champion", "DevSecOps", "shift-left security", "security technical debt".
6 / 14
During a code review of a new user registration feature, Alice comments on the PR: 'The `validate_email` function simply checks if the email address contains an @ symbol. It doesn't verify its format or domain.' What is the primary purpose of input validation like this? validate_email
Input validation is crucial for preventing malicious data from entering your system. This example highlights that simply checking for an '@' symbol is insufficient; robust validation ensures the input conforms to expected formats and rules, mitigating potential security risks like injection or misinterpretation of data. The goal is to sanitize and verify the input *before* it's processed.
7 / 14
Ben, a security engineer, sends a Slack message to the development team: 'I've seen a high number of false positives from our static analysis tool. It's flagging simple string concatenation as potentially problematic.' What does SAST stand for in this context, and what is one key difference between it and DAST? SAST
SAST (Static Application Security Testing) analyzes source code to identify potential vulnerabilities *before* the application runs. This contrasts with DAST (Dynamic Application Security Testing), which tests a running application by simulating attacks and observing its behavior. The key difference lies in when the analysis occurs – SAST is proactive, while DAST is reactive.
8 / 14
Charlie, a code reviewer, notices this code snippet: 'String filename = request.getParameter('filename'); File file = new File(filename);'. The review comment states: 'This is susceptible to a path traversal vulnerability.' What does a path traversal attack typically exploit? path traversal
A path traversal attack allows an attacker to navigate through the file system by manipulating the input used to construct a file path. By crafting a URL with specific characters like '../', they can bypass security restrictions and potentially access unauthorized files or directories on the server. This is a significant risk because it can expose sensitive data.
9 / 14
During a standup meeting, David explains a recent security finding: 'We identified that the API doesn't enforce granular object-level authorization at the /api/documents/{id} endpoint. Any user can access any document.' What type of code review finding should David primarily document? object-level authorisation
This finding describes a critical authorization issue where users are not restricted to accessing only the documents they are permitted to view. Broken authorization controls represent a significant security risk and require immediate remediation. Documenting this as an authorization flaw is the most accurate classification of the vulnerability.
10 / 14
Sarah, a junior developer, is reviewing a pull request for a new payment processing API. The PR includes this code:
```java
String amount = request.getParameter("amount");
double value = Double.parseDouble(amount);
// ... further processing...
```
The code review comment reads: 'This is vulnerable to integer overflow - consider using a `BigDecimal` object for monetary values'. What is the *primary* reason this code might be vulnerable, and what technique could Sarah use to mitigate it?
The core issue here is that `Double.parseDouble()` can easily result in an integer overflow if the input string represents a number larger than what a standard `double` can hold. Using a `BigDecimal` provides arbitrary-precision arithmetic, preventing this overflow scenario and ensuring accurate monetary calculations. Option A is incorrect because validation *is* important, but isn't the root cause of the vulnerability in this specific code.
11 / 14
Mark, a security engineer, is investigating an alert from a DAST (Dynamic Application Security Testing) tool. The tool has flagged several potential vulnerabilities related to cross-site scripting (XSS). Mark receives this message in Slack: 'Our DAST scan identified multiple instances of reflected XSS vulnerabilities across the entire application.' What does DAST stand for, and how does it differ from SAST (Static Application Security Testing)?
DAST (Dynamic Application Security Testing) tests a running application to identify security weaknesses. It simulates real user interactions and attempts to exploit vulnerabilities. SAST (Static Analysis Security Testing), conversely, analyzes source code *without* executing it, looking for potential flaws before deployment. The key difference lies in the testing environment – DAST is runtime-based, while SAST is static.
12 / 14
Emily is writing a pull request description for a new feature that allows users to upload images. She includes the following text: 'To prevent malicious uploads, we've implemented file size limits and allowed file extensions.' A senior security engineer asks her to elaborate on how this approach addresses potential vulnerabilities. What is the *most significant* limitation of relying solely on file size limits and extension checks for image security?
While file size limits and extension checks are a *basic* layer of defense, they are insufficient to protect against all image-related vulnerabilities. Malicious actors can embed executable code (like JavaScript or SVG) within seemingly harmless image files, leading to XSS or other attacks. Simply limiting the size or checking extensions doesn't prevent this embedded content.
13 / 14
Frank, a developer, is reviewing code that handles user authentication. He finds this snippet:
```python
import hashlib
password = input('Enter password: ')
hashed_password = hashlib.sha256(password.encode()).hexdigest()
// ... further processing...
```
The security review comment states: 'This code uses a simple SHA256 hash without salting, making it vulnerable to rainbow table attacks.' What is the *primary* reason this specific implementation is considered insecure?
The vulnerability lies in the absence of a 'salt' – a random string added to the password before hashing. Without a salt, an attacker can create a rainbow table (a precomputed table of hashes) and easily crack the password without needing to guess it repeatedly. Using a salt makes brute-force attacks significantly more difficult.
14 / 14
Grace is preparing a standup presentation outlining a recent security finding. She explains: 'We discovered that the application doesn't properly validate user input when constructing SQL queries, leading to potential SQL injection vulnerabilities.' Which of the following best describes the *most crucial* next step in addressing this issue?
Parameterized queries (or prepared statements) are the *standard* defense against SQL injection. They separate the query structure from the data, preventing malicious code from being interpreted as part of the query itself. While rate limiting and WAFs can provide additional layers of protection, they don't address the root cause of the vulnerability – uncontrolled user input in SQL queries.
What will I learn from the "AppSec & Secure Code Review Language | Security Lab Exercises" exercise?
Practice secure code review vocabulary: parameterised queries, SAST vs DAST, path traversal, BOLA/IDOR ownership checks, and shift-left security. 5 advanced exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 14 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Security Lab exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss security lab topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 14 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Security Lab exercises?
See the full Security Lab exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.