The OWASP approach and a security review of a web application

Objectives

By the end of the lesson, you know the ten categories of the OWASP Top 10:2025 and what it can (and cannot) be used for, you can walk a request through the trust boundaries, and you can recognize that responsibility for security is shared among several actors.

Why do we need a checking framework?

The previous lessons presented one family of attacks each. When reviewing a real application, however, we do not ask which attack we know, but what may have been forgotten. OWASP is an open professional community that helps the secure design of web applications with guides and risk summaries. Its lists do not replace the threat model of one's own system (8.1), but they give a good checking framework: which families of flaws must be thought of?

The OWASP Top 10:2025

The OWASP Top 10 organizes the frequent, important security risk categories of web applications. The ten categories of the 2025 edition:

ID	Category	Where did we meet it?
A01	Broken Access Control	7.4: authorization; 8.1
A02	Security Misconfiguration	4.3: HTTPS/HSTS, 8.2: CORS
A03	Software Supply Chain Failures	–
A04	Cryptographic Failures	4.3, 7.3, 8.6
A05	Injection	8.3, 8.5
A06	Insecure Design	8.1
A07	Authentication Failures	7.4, 8.6
A08	Software or Data Integrity Failures	–
A09	Security Logging and Alerting Failures	10.5
A10	Mishandling of Exceptional Conditions	10.2

The categories and their order can change from edition to edition. The list is not ten tests to tick off: within a single category there can be several different flaws and protection decisions. The category names are the official names that appear on the OWASP site.

The OWASP Cheat Sheet Series gives targeted, detailed guidance, for example for password storage (8.6), the prevention of SQL injection (8.5), or sessions. When using them, the concrete technology and the current documentation must be taken into account. A general list does not replace an understood data flow.

Analyzing a faulty enrolment flow

Imagine a course enrolment API. The browser sends the course and student identifiers in the request; the server checks only whether a logged-in session exists, then concatenates the two identifiers into SQL. The interface displays the note of the course as HTML without checking. The page works over HTTPS.

HTTPS protects the connection between the browser and the server (4.3), but four separate application flaws remain:

Flaw	Why is it a flaw?	Category	Fix
The hallgatoId ("student id") can be given freely	Any logged-in user can enrol in another's name.	A01	The server takes the identifier from the session (7.4).
Concatenated SQL	Injection risk.	A05	Parameterized query (8.5).
The note is displayed as HTML	XSS.	output handling (the classification of XSS can differ by edition)	Output encoding, textContent (8.3).
Cookie-based session, no intent check	CSRF.	A01/A07 (the intent of the request)	CSRF token, SameSite, Fetch metadata (8.4).

flowchart TD
    A[Course enrolment request] --> B{Who sent it?}
    B --> C{May they modify this student?}
    C --> D{Does the input stay data?}
    D --> E{Is the request the user's intention?}
    E --> F{Is the response displayed safely?}

The order of the examination is not a ranking but following the path of the request. At each node we ask: which party decides, what data does it rely on, and what happens if the data is chosen by the attacker. The student identifier is best tied to the session checked by the server, the database operation parameterized, the display handled in a text-safe way, and the operation provided with CSRF protection.

Review criteria

A short, request-based checklist (not complete):

1. Input: where does it come from, who claims it, where do we check it?
2. Authentication and authorization: does the server check at every protected operation? Does the resource belong to the person?
3. Output: is the displayed data encoded appropriately to its context?
4. Database and other interpreters: is it parameterized, does it run with least privilege?
5. Session and cookie: HttpOnly; Secure; SameSite, expiry, invalidation?
6. Connection: HTTPS everywhere, HSTS, no mixed content (4.3)?
7. Browser rules: are CORS and CSP deliberately narrow (8.2, 8.3)?
8. Secrets and dependencies: where are the secrets? What external packages does the application depend on, and are they updated?
9. Logging and alerting: would an attack attempt be visible (10.5)?
10. Error handling: does the error message reveal internal details (10.2)?

Responsibility is shared among several actors

Actor	What does it enforce?
Browser	Same-origin policy, CORS, cookie rules, CSP
Developer	The application's data flow, output handling, authorization checks, parameterization
Operator	The TLS endpoint, updates, secrets, logging, access
User	Safe login habits (long password, MFA)

The roles are connected, yet they mean separate responsibilities. The user's safe habits cannot take the place of a faulty server-side check.

Worked example: the review of Kurzuspont

In the review of Kurzuspont the team walks through the path of the enrolment request, and assigns every flaw to a category and a lesson (following the table above). The result is a list of fixes, not a "secure / not secure" verdict. The next review is triggered by a new feature, a new dependency, or an architecture change: security is not a one-time stamp.

Common misconceptions

Statement	Clarification
"The OWASP Top 10 lists every possible attack."	It gives prominent risk categories, not a complete threat model.
"If the ten items of the list are green, the system is secure."	The application's own data flows and changes must be examined too.
"The browser's security rules replace the server's checks."	The server must authenticate and authorize the operations on its own.
"An HTTPS page is secure."	It protects the connection, not the flaws of the application.
"A security review is a one-time task."	Every change can bring a new risk.

In brief

• The OWASP Top 10:2025 names ten risk categories, A01 is broken access control.
• The list gives a framework, not a complete threat model.
• A review follows the path of the request through the trust boundaries.
• Responsibility for security is shared among the browser, the developer, the operator, and the user.

Review questions

1. Into which OWASP category does it fall if a logged-in user rewrites another's identifier in the request?
2. Why does HTTPS not replace the application-level checks?
3. What does it mean that the threat model and the OWASP list complement each other?
4. Which actor is responsible for enforcing CORS and the cookie rules?

Learning resources

• OWASP Top 10:2025 — the ten categories and their detailed description.
• OWASP Cheat Sheet Series — targeted defense guides.