7 Common Web Application Security Threats

The OWASP Top 10 has not changed dramatically in twenty years. The same handful of vulnerability classes keep producing the same headlines. That is partly because attackers are conservative (why innovate when SQL injection still works?) and partly because the underlying mistakes are easy to make and hard to spot.

Here are the seven web-app threats that account for most real-world breaches, and the controls that actually stop them.

1. Injection

SQL injection, command injection, LDAP injection. The pattern is the same: untrusted input is concatenated into a query or command and the database executes whatever the attacker sends.

Fix: parameterised queries everywhere, ORMs configured to refuse string concatenation, allowlists on shell commands, and input validation as defence in depth.

2. Broken authentication

Weak passwords, no MFA, predictable session tokens, broken password reset flows. The attacker does not need to break your crypto if they can just log in as someone else.

Fix: enforce strong passwords, MFA on every account, breached-password detection at login and rotation, session tokens that are long, random, and bound to the device that minted them.

3. Cross-site scripting (XSS)

Attacker-controlled HTML or JavaScript executes in another user's browser, stealing sessions or defacing the page.

Fix: output encoding by default in your template engine, a strict Content Security Policy, HttpOnly and SameSite flags on session cookies, and Trusted Types for new frontends.

4. Broken access control

The user can access objects, endpoints, or admin pages they should not. Insecure direct object references, missing authorisation checks, and "hidden" admin URLs all sit here.

Fix: deny by default. Every endpoint enforces authorisation explicitly. Object-level checks ("does this user own this resource?") at every read and write. No security through obscurity.

5. Security misconfiguration

Default credentials still in place, debug mode in production, verbose error messages, open S3 buckets, unpatched dependencies.

Fix: hardened baseline images, infrastructure as code, automated dependency scanning, separate config for dev and prod, and regular configuration audits.

6. Sensitive data exposure

PII or credentials transmitted in plaintext, stored unencrypted, or logged where they should not be.

Fix: TLS everywhere, encryption at rest, strong key management, structured logging with PII redaction, and tokenisation of sensitive fields like card numbers.

7. Server-side request forgery (SSRF) and insecure deserialisation

Both let an attacker abuse the trust your server has in itself. SSRF tricks your backend into making a request to an internal address. Insecure deserialisation turns an attacker-controlled object into remote code execution.

Fix: egress allowlists for outbound requests, metadata endpoints behind IMDSv2 or equivalent, never deserialise untrusted data into rich object graphs, prefer JSON over native binary formats.

The meta-control: assume you are breached

Every list above is preventive. The mature programme also assumes prevention will fail somewhere. That means:

• Detection: behavioural analytics, anomaly alerts, security observability.
• Response: a runbook for credential rotation, session revocation, and incident communication.
• Containment: network segmentation so a single compromise does not become a company-wide event.

Most breaches are not novel. They are the same seven threats hitting a team that did not implement the boring controls. Implement the boring controls.