
Most web security incidents do not come from exotic attacks. They come from a small set of well-understood weaknesses that keep reappearing. The OWASP Top 10 is the best-known catalogue of them. This article explains the classes that matter most to business websites and how to prevent each one.
Broken access control
This happens when the application fails to check whether the current user is allowed to perform an action or view a record. A classic example is changing an ID in a URL and seeing someone else's data.
- Enforce authorisation on the server for every request, never only in the user interface.
- Deny by default and grant access explicitly.
- Test every role against every endpoint, including APIs.
Injection
Injection occurs when untrusted input is interpreted as part of a command or query, for example SQL. The attacker's data becomes code.
- Use parameterised queries or a trusted ORM instead of building queries from strings.
- Validate input on the server, using allow-lists where possible.
- Run database accounts with the minimum privileges they need.
// Unsafe: user input is concatenated into the query
db.query("SELECT * FROM users WHERE email = '" + email + "'");
// Safer: the value is passed separately from the query
db.query("SELECT * FROM users WHERE email = $1", [email]);Cross-site scripting (XSS)
XSS lets an attacker run script in another user's browser by getting the site to output untrusted content unescaped.
- Rely on a framework that escapes output by default and avoid bypassing it.
- Sanitise any HTML you must accept with a maintained library.
- Add a Content-Security-Policy header as defence in depth.
Authentication and session weaknesses
- Hash passwords with a modern, slow algorithm such as Argon2 or bcrypt.
- Offer multi-factor authentication for sensitive accounts.
- Rate-limit login and password-reset endpoints.
- Invalidate sessions on logout and password change.
Security misconfiguration and outdated components
Default credentials, verbose error messages, open storage buckets and unpatched libraries are everyday causes of compromise.
- Keep dependencies updated and monitor them for known vulnerabilities.
- Remove unused features, accounts and sample files.
- Review production configuration separately from development.
Server-side request forgery (SSRF)
If your server fetches URLs supplied by users, an attacker may make it reach internal services. Validate destinations against an allow-list and block requests to internal address ranges.
Where testing fits
Secure coding prevents many of these issues, and independent testing finds the ones that slip through. If you would like a second pair of eyes on an application, see our web application security testing service.
Sources
- OWASP
- Secure development
- Web security


