Bridge WAF
Web attacks: how the common ones work, and what stops them
A web attack uses an application's own requests against it: it sends input the code mishandles, or asks for something the user should not be allowed to do. Unlike a flood, it needs no volume. The pages in this section take the common web application attacks one at a time, by the name people search for them.
Quick facts
- What they target
- The application's handling of input, sessions and permissions
- Volume needed
- Usually none: a single request can be enough
- Where they are listed
- OWASP Top 10:2025 groups them into categories
- Where they are fixed
- In the application code and configuration
- What a WAF adds
- It matches recognisable attack shapes in requests, which buys time; it does not fix the code
Each attack page links up to its OWASP category, where the category's data and prevention guidance are summarised.
The attacks in this section
Three attacks account for most of what people look up, and the rest of the section follows the same pattern: what goes wrong, which OWASP category it belongs to, and what a filter can see.
| Attack | What goes wrong | OWASP category | What a WAF can see |
|---|---|---|---|
| SQL injection | Input changes a database query | A05 Injection | Most: query syntax arrives in the request |
| Cross-site scripting | Input is sent back to other users as script | A05 Injection | Part: markup in the request; not every DOM-based case |
| Cross-site request forgery | A user's browser is made to send a request they did not intend | A01 Broken Access Control | Little: the forged request looks legitimate |
| Command injection | Input reaches an operating system command or code evaluator | A05 Injection | Most: shell syntax arrives in the request |
| Server-side request forgery | The server fetches an address the attacker chose | A01 Broken Access Control | Part: obvious internal targets, not redirects or DNS tricks |
| XML external entities | An XML parser fetches files or URLs named in the document | A02 Security Misconfiguration | Part: entity declarations in plain XML bodies |
| Clickjacking | Another site frames your page under a decoy | A06 Insecure Design | None: it happens in the browser |
| Path traversal | A file name in the request climbs out of the intended folder | A01 Broken Access Control | Most: traversal sequences in parameters |
| CRLF injection | Line breaks in input start new headers or log lines | A05 Injection | Part: encoded line breaks in single-line values |
| HTTP request smuggling | A front-end and a back-end disagree on where a request ends | A06 Insecure Design | Part: conflicting length headers, where the filter refuses them |
| Business logic flaws | Valid requests produce outcomes the business never intended | A06 Insecure Design | None: there is no pattern to match |
| Insecure direct object reference | Changing an identifier reaches another user's object | A01 Broken Access Control | None: the request is valid |
| Session hijacking | A stolen or planted session token is used as the user | A07 Authentication Failures | Little: the script that steals cookies, not the stolen token |
| CORS misconfiguration | A response lets any site read a signed-in user's data | A02 Security Misconfiguration | None: it is in the response and the browser |
More attacks are added to this section as their pages are written; the OWASP category pages already describe the others at category level.
Why web attacks work
Almost every web attack comes down to one of three mistakes: data that is treated as instructions, a request that is trusted because of where it seems to come from, or a permission that is checked in the page but not on the server.
None of these is visible from outside until someone tries it, which is why the same few attacks have stayed common for years. The fix is known for each; applying it everywhere is the hard part.
What a WAF can and cannot do about them
A web application firewall reads requests, so it does well where an attack has to put recognisable syntax into one: query fragments, script tags, command separators. It can refuse those while the code is fixed, which is called virtual patching.
It does poorly where the attack request is indistinguishable from a real one: a forged request carrying the victim's own cookies, or a request for another user's record. Those are fixed only in the application, by checking intent and ownership on the server.
Where to start fixing
- Keep data out of instructions. Parameterised queries and output encoding close injection and cross-site scripting.
- Check every request on the server. Ownership, role and intent, not only what the page allowed the user to click.
- Make cookies harder to misuse. The SameSite attribute and anti-forgery tokens stop forged cross-site requests.
- Watch before enforcing. Run filtering in monitor mode first to see which of your own fields look like attacks.
Questions
What are web attacks?
Web attacks are attacks on a website or web application through its own requests: input that the code mishandles, or requests for actions the user should not be allowed to take. SQL injection, cross-site scripting and cross-site request forgery are the most common.
What is the most common web application attack?
Injection attacks, including SQL injection and cross-site scripting, are among the most common; OWASP places injection in its Top 10:2025, alongside broken access control in first place.
Can a WAF stop web attacks?
Partly. A WAF can refuse requests carrying recognisable attack syntax, which protects vulnerable code while it is fixed. It cannot stop attacks that look like legitimate requests, such as forged requests or access to another user's data.