Web Application Security in Practice

The web application is an organisation's most exposed component: reachable by anyone from the internet, with every function a potential entry point. The OWASP Top 10 is the priority list for this area, but the list alone is abstract. This article focuses on what actually appears in real tests.

1. Broken access control

By a clear margin the most common and most serious category. The typical case: the application checks whether the user is signed in but not whether they are entitled to the specific resource.

Change /invoice/1234 in the URL to 1235 and someone else's invoice appears. This takes minutes to find and occurs in most tests.

What to do: verify server-side on every request that the authenticated user is entitled to that object. Client-side checking is not checking.

2. Injection

The attacker passes a command disguised as data into an interpreter. Classically SQL, but the same exists for shells, LDAP and template engines.

What to do: parameterised queries. Not input filtering, which can always be bypassed, but ensuring data never reaches the instruction position.

3. Authentication failures

Weak password policy, missing account lockout, predictable session identifiers, sessions that survive logout.

What to do: MFA, secure session handling (random identifiers, HttpOnly and Secure cookies, sensible expiry), and rethinking the password reset flow, which is often weaker than login itself.

4. Security misconfiguration

Default credentials, verbose error messages in production, an exposed admin interface, directory listing, outdated components.

What to do: a documented baseline with automated verification. Production error messages should never contain stack traces or database information.

5. Vulnerable components

Most modern applications consist largely of third-party code. A library with a known vulnerability carries the same risk as a flaw in your own code.

What to do: dependency inventory and automated scanning. We covered this in our software dependencies article.

6. XSS

The attacker injects a script into the page that runs in the visitor's browser, enabling session cookie theft or actions on their behalf.

What to do: context-aware output encoding, HttpOnly cookies, and a Content Security Policy restricting where scripts may load from.

What a scanner cannot find

Business logic flaws. Negative quantities in a basket, reusing a coupon, skipping workflow steps. These require understanding what the application does.

Privilege chains. A low-privileged user reaching another role's functionality.

Race conditions. Two parallel requests creating a state that is otherwise impossible.

This is why scanning and penetration testing do not substitute for each other.

What to fix first

1. Authorisation checks on every resource access, server-side
2. Parameterised queries everywhere data enters a query
3. MFA on login and on password reset
4. Keeping dependencies current with automated scanning
5. Security headers: CSP, HSTS, X-Content-Type-Options

These five cover the overwhelming majority of flaws found in real tests. We covered testing on our penetration testing page.