Security testing and the OWASP Top 10

You wrote secure code, but is it really secure? The only way to know is to test. This page is the verification and validation leg of the secure SDLC: which testing technique finds which vulnerability, and which one misses what. The second half has the OWASP Top 10 (2021). The two most common types on the exam: “what does this technique do / which one doesn’t execute the code” and “which OWASP category is this scenario”. In between, small calculations such as precision/recall or a fuzzing probability may appear.

Golden rules:

1. One technique isn’t enough. Static analysis, dynamic testing and human review find different flaws.
2. Early testing is cheap. SAST and code review work while the code is being written.
3. Tool output is raw data. Every finding must be verified; a false positive is noise, a false negative is a blind spot.
4. No testing without permission. A pentest is done with written permission and a clear scope.
5. Recognize the OWASP list from the scenario. Memorizing category names is not enough, match them with examples.

Security testing techniques

Static analysis (SAST)

SAST marks the place where input comes in as the source, and the place where it is used dangerously as the sink, and checks whether there is sanitization on the path in between. This is called taint analysis.

String id = request.getParameter("id");              // source: untrusted
String sql = "SELECT * FROM orders WHERE id = " + id;
stmt.executeQuery(sql);                               // sink: SQL engine
// SAST warning: tainted data flows from getParameter to executeQuery

Advantage: it doesn’t need a running system yet, and it examines every path. Disadvantage: it can’t always tell that a value is actually harmless, so it produces false alarms.

Measuring a tool’s success: precision and recall

Say a tool reports 60 findings and 45 of them are real. Say the code has 50 real vulnerabilities in total.

$\text{precision} = \frac{TP}{TP+FP} = \frac{45}{60} = 0.75 \qquad \text{recall} = \frac{TP}{TP+FN} = \frac{45}{50} = 0.90$

In security a false negative is more dangerous (the vulnerability goes live), but a very low precision makes the developer switch the tool off. A balance is struck between the two.

Dynamic analysis (DAST)

DAST tests the running application without seeing the source code: it fills in forms, puts special characters in parameters, and looks in the response for error messages, reflected input and missing security headers (Content-Security-Policy, Strict-Transport-Security). Since it tests the real environment, it sees configuration errors; but it tests only the pages it can reach. IAST combines the two by placing an agent inside the application.

Fuzzing

A fuzzer gives the program unexpected input and looks for crashes, infinite loops and memory errors. It is especially effective for file format parsers, network protocols and C/C++ code.

Why are many inputs needed? If a bug is triggered with probability $p$ per input, the probability that it is triggered at least once in $n$ independent inputs is:

$P = 1 - (1-p)^n \approx 1 - e^{-np}$

For $p = 10^{-4}$, $n = 10\,000$ gives $P \approx 0.6321$. To catch the same bug with high probability, the number of inputs has to be increased several times. Coverage-guided fuzzing tries precisely to increase this $p$.

PITFALL · fuzzing doesn’t find every vulnerability. Bugs that don’t produce a crash (e.g. IDOR, a wrong authorization check) are invisible to a fuzzer. The program returns the “right” response but shows someone else’s data. These are found by code review and pentest.

Penetration testing

A pentest is an authorized expert testing the system through an attacker’s eyes, but with written permission and within a defined scope. The goal is to find the vulnerability and report it to the owner.

Typical phases: scope and rules of engagement → information gathering → vulnerability scanning → controlled verification of findings → reporting (with risk level and remediation advice) → retest after the fix. The report is the real product of the test.

OWASP Top 10 (2021)

OWASP (Open Worldwide Application Security Project) publishes the most critical risk categories in web applications every few years. The 2021 list:

Important changes from 2017 to 2021: Broken Access Control rose from fifth to first; XSS stopped being a separate category and was merged into Injection; Insecure Design, Software and Data Integrity Failures and SSRF were added as new categories.

TIP · finding the category from the scenario. First ask: is the identity correct? If so, but unauthorized data is being accessed, it is A01; if the identity itself is the problem, A07. If data goes to an interpreter as code, A03. If the setting is wrong, not the code, A05. If the hole is in someone else’s library, A06. If the server goes to an address given by the user, A10.

Which test catches which category well? SAST is strong on A03, SCA is a perfect fit for A06, and DAST is good on A05. A01 and A04 are mostly human work: code review, threat modeling and pentest.

Common mistakes