After many web application penetration tests, the same vulnerability classes show up again and again — and they are rarely exotic. They are the fundamentals, done wrong. This guide walks the web vulnerabilities we exploit most, why they happen, and what they let an attacker do.
1. Broken access control & IDOR
The reigning OWASP #1. The application authenticates you correctly but fails to check authorisation — so by changing an ID in a URL or request you reach another user’s data or actions. It is devastating and extremely common because the check is easy to forget on every single endpoint. This is the focus of broken access control & IDOR testing.
2. Injection (SQL, command, template)
When untrusted input reaches an interpreter without proper separation of code and data, an attacker can rewrite the query or command. SQL injection can dump an entire database; command injection can take over the server. Parameterised queries and strict input handling prevent it — yet it persists wherever legacy code or string concatenation lives.
3. Cross-site scripting (XSS)
The app reflects or stores attacker-controlled input and a victim’s browser executes it as script — enabling session theft, credential harvesting and UI manipulation. Reflected, stored and DOM-based variants each need different tests, which is why XSS testing is a category of its own.
4. Server-side request forgery (SSRF)
The application fetches a URL an attacker controls, letting them reach internal services and — in cloud environments — the metadata endpoint that hands out credentials. SSRF has driven some of the largest cloud breaches on record; see SSRF testing.
5. Business-logic flaws
No scanner finds these. The code works exactly as written — but the workflow can be abused: negative quantities, skipped payment, coupon stacking, race conditions, multi-step processes done out of order. On shops the impact is direct financial loss, which is why e-commerce testing treats logic as a first-class target.
6. Authentication & session weaknesses
Weak password policy, missing brute-force protection, predictable tokens, and — most commonly — flawed password-reset and email-change flows that hand over accounts. On multi-tenant platforms these bugs cross tenant boundaries; see SaaS penetration testing and SPA testing for how modern front ends complicate session handling.
7. Security misconfiguration & exposed secrets
Default credentials, verbose error messages, open debug endpoints, missing security headers, and API keys committed to code or left in front-end bundles. Individually minor, they are the footholds attackers chain into full compromise.
The pattern behind them all
Almost every finding above comes down to trusting input or forgetting to check authorisation. Fix those two habits across every endpoint and you eliminate most of the risk. The catch is “every endpoint” — which is exactly what manual testing verifies and scanners cannot. These map directly to the OWASP Top 10.
Frequently asked questions
Which of these is most dangerous? Broken access control, because it is both the most common and often the highest impact — direct access to data that isn’t yours.
Can automated tools catch these? Scanners catch some injection and XSS, but miss access-control and business-logic flaws almost entirely. Those need a human — see pentest vs scan.
Want to know which of these your app is exposed to? Explore web application penetration testing or get a fixed-price quote — usually within one business day.