Web vulnerabilities are the most common entry point for real-world attacks. Broken access control, injection flaws, and authentication failures appear in breaches across every industry, every year. Understanding how to find them and how to fix them is the foundational skill set for both penetration testers and developers who take security seriously.
This guide covers the OWASP Top 10 2025 - the most widely cited web application security standard in the world - with practical guidance on what each vulnerability looks like, how to find it, and how to remediate it.
What Is the OWASP Top 10 and Why Does It Matter?
The OWASP Top 10 is updated every four years by the Open Web Application Security Project. It provides a high-level grouping of security weaknesses that are most prevalent in real-world web applications, based on contributed test data and CVEs. The 2025 edition introduced two new categories reflecting modern attack patterns: Software Supply Chain Failures and Mishandling of Exceptional Conditions.
For beginners, the OWASP Top 10 is the syllabus. Learn these ten categories and you understand the vulnerability classes that appear in the majority of real web application assessments. Every web penetration tester, bug bounty hunter, and application security engineer is expected to know them.
The OWASP Top 10 2025: Find It and Fix It
A01: Broken Access Control
Broken Access Control is the most common web application vulnerability. It occurs when users can access resources or actions they should not be able to.
What it looks like in practice: A user changes their account ID in a URL from ?id=123 to ?id=124 and sees another user's data. An admin panel is accessible without any authentication check. A user with read access can call an API endpoint that performs deletions.
How to find it: Test every function the application performs and ask: what happens if I change the user identifier? Can I access this endpoint without being logged in? Can I perform this action as a lower-privilege user? Burp Suite's Repeater module is the primary tool for this kind of manual testing.
How to fix it: Enforce access control checks server-side on every request. Never rely on hiding URLs or using client-side checks alone. Implement deny-by-default and require explicit grants for each resource.
A02: Cryptographic Failures
This category covers data transmitted in cleartext, deprecated hash functions (MD5, SHA1), passwords used as cryptographic keys, and insufficient randomness. When cryptographic protections fail, attackers can intercept credentials in transit, decrypt stored data, or forge authentication tokens.
What it looks like in practice: Passwords stored as MD5 hashes. Session tokens with predictable patterns. Sensitive data transmitted over HTTP rather than HTTPS.
How to find it: Check HTTP vs HTTPS for all sensitive data. Look for hash values in source code, cookies, or URLs and identify the algorithm. Test whether session tokens are predictable by generating several in sequence.
How to fix it: Use HTTPS everywhere with HSTS enforced. Store passwords with bcrypt, scrypt, or Argon2. Use cryptographically secure random number generators for tokens and nonces. Never use MD5 or SHA1 for password hashing.
A03: Broken Access Control (IAAA Failures)
The 2025 edition restructures this into identity, authentication, authorisation, and accounting failures, reflecting that the root cause of most access control issues is poor identity management rather than just missing checks.
How to find it: Test login throttling: does the application lock after multiple failed attempts? Test session invalidation: does logging out actually invalidate the session token server-side? Test multi-factor authentication: can it be bypassed by replaying a token?
How to fix it: Implement MFA. Enforce login throttling with exponential backoff. Invalidate sessions properly on logout and password change. Use standardised authentication frameworks rather than building your own.
A04: Insecure Design
Insecure Design occurs when security is not considered during the design phase. Design flaws are hard to fix after development. Addressing them early reduces future vulnerabilities and builds stronger, safer applications.
What it looks like in practice: A password reset flow that leaks the reset token in the URL. An application that allows unlimited account enumeration through its "forgot password" feature. A checkout process that performs no server-side price validation.
How to find it: Work through every user flow and ask: what is the intended security model here? Is there a way to subvert the intended sequence? Business logic flaws are often the hardest vulnerabilities to find automatically and the most valuable to discover manually.
How to fix it: Conduct threat modelling before writing code. Establish abuse case testing alongside functional tests. Apply secure design patterns from the OWASP Proactive Controls.
A05: Injection
Injection is one of the most tested categories, with the greatest number of CVEs associated with the 38 CWEs in this category. Injection includes a range of issues from Cross-site Scripting (high frequency/low impact) to SQL Injection (low frequency/high impact) vulnerabilities.
SQL injection - how to find it: Enter a single quote ' in any input field that queries a database. If the application returns a database error or behaves unexpectedly, the input is likely being passed to a SQL interpreter unsanitised. Burp Suite's active scanner and sqlmap are the standard tools for systematic testing.
XSS - how to find it: Enter <script>alert(1)</script> in every input field that renders output. Reflected XSS fires immediately. Stored XSS fires when another user views the page containing your input. DOM-based XSS requires reading the JavaScript that handles your input to identify sink functions.
How to fix injection: Use parameterised queries for all database operations. Validate and sanitise all user input, and escape output for the specific rendering context (HTML, JavaScript, SQL). Apply content security policies to reduce XSS impact.
A06: Security Misconfiguration
The most commonly found vulnerability in assessments of real-world applications. Default credentials left unchanged. Admin interfaces exposed to the internet. Directory listing enabled. Verbose error messages revealing stack traces and internal paths.
How to find it: Walk through every configuration the application exposes: default credentials on admin panels, exposed .git directories, open S3 buckets, unnecessary HTTP methods enabled, verbose server headers. Gobuster and Nikto surface many of these automatically.
How to fix it: Build security into deployment pipelines. Use infrastructure as code with security scanning. Remove or disable every feature, service, and account that is not actively required.
A07: Authentication Failures
Weak passwords accepted. No lockout after failed attempts. Session tokens that do not expire. Credentials transmitted in cleartext. Password reset links that do not expire.
How to find it: Try default credentials on admin interfaces. Test whether session tokens remain valid after logout. Check whether password reset tokens expire and whether they can be reused.
How to fix it: Enforce MFA. Implement login throttling. Use secure session management with short-lived tokens. Invalidate tokens server-side on logout.
A08: Software and Data Integrity Failures
Applications that pull dependencies from unverified sources, deserialise untrusted data without validation, or auto-update without verifying signatures are vulnerable to supply chain attacks and remote code execution.
How to find it: Review all third-party dependencies and their sources. Test deserialisation endpoints by sending malformed serialised objects. Check whether software updates verify cryptographic signatures.
How to fix it: Use software composition analysis (SCA) to track dependency integrity. Sign all software releases. Validate and sanitise any serialised data before processing.
A09: Security Logging and Monitoring Failures
Not a vulnerability an attacker exploits directly, but a gap that allows attacks to go undetected. Applications that do not log authentication events, failed access attempts, or high-value transactions give attackers extended dwell time.
How to find it: Trigger events that should be logged: failed logins, access control violations, input validation failures. Check whether those events actually appear in logs. Test whether alerts fire within a reasonable time.
How to fix it: Log all authentication events, access control failures, and server-side input validation failures. Ensure logs are stored in a format that can be monitored and are forwarded to a SIEM. Set alerting thresholds for suspicious patterns.
A10: Mishandling of Exceptional Conditions (New in 2025)
A new category for OWASP Top 10 2025. Focuses on how systems behave under abnormal conditions: exceptions, unexpected inputs, fail-open logic, error handling vulnerabilities. Attackers increasingly exploit edge cases and exception paths - code paths that were not well covered in design and test.
How to find it: Send unexpected input types: null values, very long strings, special characters, negative numbers where positive numbers are expected. What does the application do? Does it fail open (grant access) or fail closed (deny access)?
How to fix it: Audit exception handling flows. Ensure that when something goes wrong, the application defaults to the most secure state rather than the most permissive one.
Find and Fix: The Quick Reference Table
| Vulnerability | Quick find test | Primary tool | Core fix | Practise on TryHackMe |
|---|---|---|---|---|
| Broken Access Control | Change user IDs in URLs and API calls | Burp Suite Repeater | Server-side access checks on every request | Jr Penetration Tester path |
| SQL Injection | Enter ' in input fields, observe errors | Burp Suite, sqlmap | Parameterised queries, never string concatenation | Jr Penetration Tester path |
| XSS | Enter <script>alert(1)</script> in inputs | Burp Suite, browser dev tools | Output encoding, Content Security Policy | Jr Penetration Tester path |
| IDOR | Change object references in requests | Burp Suite Repeater | Validate ownership server-side before serving data | Jr Penetration Tester path |
| Authentication failures | Test lockout, session expiry, reset token reuse | Burp Suite Intruder | MFA, login throttling, server-side session invalidation | Jr Penetration Tester path |
| Security misconfiguration | Check default creds, exposed dirs, verbose errors | Gobuster, Nikto | Disable everything not actively required | Jr Penetration Tester path |
Where Can You Practise Finding and Fixing Web Vulnerabilities?
TryHackMe's Jr Penetration Tester path is the most structured hands-on route through web application security. The path was completely rebuilt for 2026 and now includes a full web security curriculum aligned to the 2025 OWASP Top 10, with dedicated modules covering SQL injection, XSS, CSRF, SSRF, IDOR, authentication bypass, and API testing. Every room puts you inside a live vulnerable application in a browser. No local setup required.
For self-directed practice without guided structure, DVWA (Damn Vulnerable Web Application) and OWASP Juice Shop are the standard free local environments. Juice Shop has over 100 vulnerabilities across all difficulty levels with a built-in challenge tracker. Run them in Docker:
bash
# Juice Shop
docker run --rm -p 3000:3000 bkimminich/juice-shop
# DVWA
docker run --rm -p 80:80 vulnerables/web-dvwa
FAQ
How do I learn cross-site scripting (XSS) from scratch? Start with reflected XSS: find an input field that echoes your input back in the page, enter <script>alert(1)</script>, and observe whether the browser executes it. DVWA has an XSS module at low, medium, and high difficulty that walks you through progressively hardened implementations. TryHackMe's Jr Penetration Tester path covers XSS introduction as a dedicated room in the web vulnerabilities module. Once you understand reflected XSS, move to stored XSS (where your payload is saved to the database and fires for other users) and then DOM-based XSS (where client-side JavaScript processes your input without server involvement).
How do I get into bug bounty hunting as a beginner? Bug bounty requires solid web application security fundamentals first. Work through the OWASP Top 10 in a hands-on environment, develop Burp Suite proficiency, and practise finding vulnerabilities in intentionally vulnerable applications (DVWA, Juice Shop, TryHackMe rooms) before targeting live programmes. When you are ready, start with public programmes on HackerOne or Bugcrowd that explicitly welcome beginners, have a wide scope, and pay for lower-severity findings. Document everything meticulously - your report quality determines whether a finding is accepted regardless of technical accuracy.
What are the best resources for learning web application security? TryHackMe's Jr Penetration Tester path is the most structured hands-on route for beginners, covering the full OWASP Top 10 2025 curriculum with live labs. PortSwigger Web Security Academy is entirely free and goes extremely deep on every web vulnerability class from beginner through expert, with interactive labs throughout. OWASP's own documentation, including the OWASP Testing Guide and OWASP Cheat Sheet Series, is the authoritative reference for both finding and fixing vulnerabilities. For Burp Suite proficiency specifically, PortSwigger's own learning materials are the best source.
What is the difference between finding and fixing a web vulnerability? Finding a vulnerability means identifying that it exists, demonstrating it is exploitable, and documenting the evidence. Fixing it means changing the code, configuration, or architecture so the vulnerability cannot be exploited. Penetration testers primarily focus on finding. Developers primarily focus on fixing. The best practitioners understand both sides: testers who understand remediation write more actionable reports, and developers who understand exploitation write more secure code.
Nick O'Grady