Web Application Security: Common Vulnerabilities, How They Work, and How to Fix Them

Every web application accepts user input. Every web application connects to a database. Every web application makes decisions about who can access what. And every one of those operations, if implemented incorrectly, creates a vulnerability an attacker can exploit.

The uncomfortable truth about web application security is that the same vulnerability categories discovered in the early 2000s still dominate breach reports today. SQL injection. Cross-site scripting. Broken access control. Authentication failures. These aren't exotic, novel attacks. They're well-understood problems with well-documented solutions that organisations keep shipping in production because developers are under deadline pressure, security testing happens too late, and nobody catches the flaw until an attacker or a penetration tester finds it.

This guide covers the most common web application security vulnerabilities that professional penetration testing consistently discovers, explains how each one works in practical terms, provides specific fix guidance developers can implement, and outlines the web application security best practices that prevent these vulnerabilities from reaching production.

This isn't a theoretical taxonomy. Every vulnerability covered here is something we see in real-world web application security testing engagements, ranked by how frequently it appears and how much damage it causes.

1. Broken Access Control

What it is: Users accessing data or functionality they shouldn't be able to reach.

How common: The single most frequently discovered web application security vulnerability category. OWASP ranks it #1. AppSecure finds access control issues in the majority of web application assessments.

How It Works

Insecure Direct Object Reference (IDOR). The application uses user-controllable identifiers (IDs in URLs, request parameters) to retrieve data without verifying the requesting user owns that data.

A request to /api/invoices/1234 returns your invoice. Changing it to /api/invoices/1235 returns someone else's invoice. The application checked that you're logged in but never checked that invoice 1235 belongs to you.

Privilege escalation. A standard user accesses administrative functionality by modifying URLs, changing parameters, or calling API endpoints directly. The application hides admin features in the UI but doesn't enforce access on the server.

Forced browsing. Directly accessing pages or endpoints by URL without going through the intended navigation path. Admin panels at /admin, user management at /api/users/all, or debug endpoints at /debug/logs accessible to anyone who guesses the URL.

How to Fix It

Implement server-side authorisation on every request. Never rely on the UI to restrict access. Every API endpoint and page must independently verify that the requesting user is authorised to access the specific resource or function.

Use indirect references. Instead of exposing database IDs in URLs (sequential, guessable), use mapping functions that convert internal IDs to session-specific references the user can't manipulate to access other records.

Deny by default. Start with no access and explicitly grant permissions rather than starting with full access and trying to restrict. Deny-by-default catches the cases you forget to restrict.

Centralise access control logic. Implement authorisation in a shared middleware or framework layer rather than in each individual endpoint. Centralised enforcement prevents the inconsistency where nine endpoints check permissions and the tenth doesn't.

Test it properly. Automated scanners cannot reliably detect IDOR because they don't understand data ownership. Manual penetration testing is essential for thorough access control validation.

2. Injection Vulnerabilities

What it is: User-supplied data interpreted as code or commands by backend systems.

How common: Despite decades of awareness, injection remains a top web application security vulnerability because it appears wherever user input reaches an interpreter without proper handling.

SQL Injection

How it works: User input is inserted directly into SQL queries. An attacker provides input containing SQL syntax that modifies the query's behaviour: extracting additional data, bypassing authentication, modifying records, or accessing the entire database.

A login form sending SELECT * FROM users WHERE username = '[input]' AND password = '[input]' allows an attacker to input ' OR '1'='1 as the username, modifying the query to return all users and bypass authentication entirely.

How to fix it: Use parameterised queries (prepared statements) for every database interaction. Parameterised queries separate data from SQL syntax, making injection impossible regardless of what the user provides. Never concatenate user input into SQL strings.

Cross-Site Scripting (XSS)

How it works: The application includes user-supplied data in web pages without proper encoding, allowing attackers to inject JavaScript that executes in other users' browsers. Reflected XSS sends malicious scripts through URLs. Stored XSS saves malicious scripts in the application (comments, profiles) that execute when other users view the content. DOM-based XSS exploits client-side JavaScript that manipulates the page based on user-controllable input.

How to fix it: Apply context-aware output encoding to all user-generated content. HTML entities for HTML context. JavaScript encoding for JavaScript context. URL encoding for URL context. Implement Content Security Policy (CSP) headers restricting script sources. Set HttpOnly flag on session cookies preventing JavaScript access.

Command Injection

How it works: User input reaches operating system command execution. An attacker appends shell commands to legitimate input, executing arbitrary commands on the server.

How to fix it: Avoid calling OS commands with user input entirely. If unavoidable, use language-specific APIs that don't invoke shell interpreters. Apply strict input validation allowing only expected characters.

Server-Side Request Forgery (SSRF)

How it works: The application makes HTTP requests to URLs the user provides without validating the destination. Attackers redirect requests to internal services, cloud metadata endpoints (169.254.169.254), or other resources the server can access but the attacker cannot reach directly.

See our comprehensive SSRF vulnerability guide for exploitation techniques and prevention.

How to fix it: Implement URL allowlists for permitted destinations. Block internal IP ranges and metadata addresses. Validate resolved IP addresses (not just hostnames). Restrict URL schemes to http/https only. Enforce AWS IMDSv2. Segment application servers from sensitive internal services.

Server-Side Template Injection (SSTI)

How it works: User input is embedded in server-side templates (Jinja2, Twig, Freemarker) and processed by the template engine. Attackers inject template expressions that execute code on the server, potentially achieving remote code execution.

How to fix it: Never pass user input directly into template expressions. Use templates only for presentation logic. Sandbox template engines where possible. Apply strict input validation.

3. Authentication and Session Vulnerabilities

What it is: Weaknesses in how the application verifies user identity and maintains authenticated sessions.

Weak Password Policies

How it works: The application allows short, common, or previously breached passwords. Attackers use credential stuffing (trying known username/password pairs from other breaches) or brute-force to compromise accounts.

How to fix it: Enforce minimum 12-character passwords. Check passwords against breach databases (Have I Been Pwned API). Implement progressive lockout or delay after failed attempts. Support and encourage MFA.

Broken Session Management

How it works: Session tokens that are predictable, don't expire, aren't invalidated on logout, or are transmitted insecurely. Session fixation where the application doesn't issue a new session ID after authentication. Sessions persisting after password change.

How to fix it: Generate cryptographically random session tokens. Invalidate sessions server-side on logout (don't just delete the cookie). Set appropriate session timeout. Issue new session IDs after authentication and privilege changes. Set Secure, HttpOnly, and SameSite attributes on session cookies.

JWT Implementation Weaknesses

How it works: JSON Web Tokens with weak signing secrets (brute-forceable), missing algorithm validation (accepting "none" algorithm), missing expiration, or client-side token modification.

How to fix it: Use strong signing secrets (256+ bits of entropy). Validate the algorithm server-side (reject "none" and unexpected algorithms). Enforce token expiration. Use asymmetric algorithms (RS256, ES256) for higher security.

Missing or Bypassable MFA

How it works: MFA not enforced on sensitive operations. MFA bypassed through backup code brute-force, session fixation after first factor, or MFA status stored client-side where it can be modified.

How to fix it: Enforce MFA server-side. Rate-limit backup code attempts. Require MFA re-verification for sensitive operations (password change, email change, payment). Don't store MFA completion status in client-accessible tokens.

4. Security Misconfiguration

What it is: Insecure default settings, unnecessary features, verbose errors, or missing security controls in the application or its hosting environment.

Verbose Error Messages

How it works: Stack traces, database error messages, or framework details exposed in production error responses. Attackers use these to understand backend technology, database structure, file paths, and internal logic.

How to fix it: Return generic error messages to users. Log detailed errors server-side for debugging. Never expose stack traces, SQL queries, or internal paths in production responses.

Missing Security Headers

How it works: Absent HTTP security headers leave browsers without security guidance. Missing HSTS allows protocol downgrade. Missing CSP allows script injection. Missing X-Frame-Options enables clickjacking.

How to fix it: Implement all standard security headers: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options or CSP frame-ancestors, X-Content-Type-Options: nosniff, Referrer-Policy, and Permissions-Policy. Apply headers globally through web server or application framework configuration.

Default Credentials

How it works: Administrative interfaces, databases, or application components running with manufacturer default passwords. Attackers check default credentials first because they work surprisingly often.

How to fix it: Change every default credential before deployment. Scan for default credentials during security testing. Include default credential checking in deployment checklists.

Debug Features in Production

How it works: Debug endpoints, verbose logging, test accounts, or development tools accessible in production. Debug endpoints often bypass authentication and expose internal application state.

How to fix it: Remove all debug functionality from production builds. Use environment-specific configuration preventing debug features from activating in production. Scan for common debug paths (/debug, /test, /console, /actuator) during deployment.

Overly Permissive CORS

How it works: Cross-Origin Resource Sharing configured with wildcard origins or reflecting the requesting origin, allowing any website to make authenticated API requests to your application.

How to fix it: Configure CORS with explicit, restrictive origin allowlists. Never use Access-Control-Allow-Origin: * for endpoints handling authenticated requests. Don't reflect the Origin header value without validation.

5. Vulnerable and Outdated Components

What it is: Using third-party libraries, frameworks, or server software with known security vulnerabilities.

How it works: Applications include dozens to hundreds of third-party dependencies. Each dependency may contain known CVEs. Attackers target known vulnerabilities in popular libraries because exploitation is reliable and widely documented.

How to fix it: Maintain a software bill of materials (SBOM) for all dependencies. Run Software Composition Analysis (SCA) tools (Snyk, Dependabot, OWASP Dependency-Check) identifying known CVEs. Update dependencies regularly. Remove unused dependencies. Monitor for new CVE disclosures affecting your dependency tree.

6. Insecure File Upload

What it is: File upload functionality that doesn't adequately validate uploaded files, enabling attackers to upload malicious content.

How it works: An attacker uploads a PHP/JSP/ASP file through an image upload field. If the server stores the file in a web-accessible directory and executes it, the attacker achieves remote code execution. Even without execution, malicious files can contain embedded scripts (SVG with JavaScript), exploit image processing libraries, or overwrite critical files through path traversal in filenames.

How to fix it: Validate file types server-side using magic bytes (file content), not just file extension or Content-Type header. Store uploaded files outside the web root. Rename files with random names (don't preserve user-provided filenames). Set Content-Disposition: attachment for downloads. Scan uploads for malware. Limit file size. Re-process images to strip metadata and embedded content.

7. Business Logic Vulnerabilities

What it is: Flaws in the application's business workflow that enable abuse the developer didn't anticipate.

How common: Business logic flaws consistently produce the highest-severity findings in web application penetration testing because they're application-specific and no automated scanner can detect them.

Common Business Logic Flaws

Price manipulation. Modifying price values in requests during checkout. The frontend displays $99.99. The attacker changes the request to $0.01. The server processes the modified price without validation.

Workflow bypass. Skipping required steps in multi-step processes. Submitting the final step of an application process without completing identity verification. Accessing post-payment content without completing payment.

Race conditions. Submitting concurrent requests to exploit time-of-check-to-time-of-use gaps. Transferring money from an account simultaneously from two sessions, overdrawing the balance before the first transaction completes.

Coupon and reward abuse. Applying coupons multiple times, using expired promotions, self-referral loops, or stacking discounts in unintended combinations.

How to Fix Business Logic Vulnerabilities

Validate all business rules server-side. Never trust client-submitted prices, quantities, or business values. Recalculate totals server-side. Verify workflow completion status server-side.

Implement idempotency for financial operations. Use idempotency keys preventing duplicate transaction processing. Lock resources during critical operations to prevent race conditions.

Design for abuse. During feature design, ask: "What happens if someone submits this request with unexpected values? What if they skip this step? What if they repeat this action?" Threat modelling identifies business logic risks before code is written. See our threat modelling guide.

Test with manual experts. Business logic testing requires human understanding of intended application behaviour. No automated tool knows your checkout workflow, approval process, or financial rules. Manual penetration testing is the only reliable method for business logic vulnerability discovery.

8. Cryptographic Failures

What it is: Weak, improperly implemented, or missing encryption exposing sensitive data.

Common Cryptographic Failures

Data transmitted over HTTP. Sensitive data (credentials, personal information, payment data) sent without TLS encryption, interceptable by network attackers.

Weak hashing algorithms. Passwords stored using MD5 or SHA-1 instead of modern password hashing algorithms (bcrypt, scrypt, Argon2).

Hardcoded encryption keys. Encryption keys embedded in source code, configuration files, or version control where they're discoverable.

Insufficient TLS configuration. Outdated TLS versions (1.0, 1.1), weak cipher suites, or missing HSTS enabling protocol downgrade attacks.

How to Fix Cryptographic Failures

Enforce HTTPS everywhere with HSTS. Use bcrypt, scrypt, or Argon2 for password hashing with adequate work factors. Store encryption keys in dedicated key management services (AWS KMS, Azure Key Vault, HashiCorp Vault), never in code. Enforce TLS 1.2+ with strong cipher suites. Encrypt sensitive data at rest in databases and storage.

9. Insufficient Logging and Monitoring

What it is: The application doesn't log security-relevant events or doesn't monitor logs for suspicious activity.

How it works: Without logging, attackers operate undetected. Failed login attempts, access control violations, input validation failures, and administrative actions go unrecorded. When a breach occurs, investigation lacks the data needed to understand what happened, when, and how far the compromise extends.

How to fix it: Log authentication events (success and failure), access control failures, input validation failures, and high-value transactions. Include timestamp, user identity, source IP, and action details. Don't log sensitive data (passwords, tokens, full credit card numbers). Forward logs to SIEM. Configure alerting for suspicious patterns. Ensure log integrity through append-only storage or tamper detection.

Web Application Security Best Practices

1. Shift Security Left

Integrate security into every phase of development, not just the final testing stage. Security requirements during design. Secure coding standards during development. Automated security scanning in CI/CD. Manual penetration testing before major releases.

Building security into the secure SDLC prevents vulnerabilities rather than discovering them post-deployment.

2. Validate All Input Server-Side

Never trust client-side validation. Attackers bypass the frontend and call APIs directly. Every parameter from every source (request body, URL, headers, cookies) must be validated server-side for type, length, format, and range.

3. Use Security Frameworks and Libraries

Don't build authentication, session management, or encryption from scratch. Use established, maintained frameworks that handle security correctly by default. Custom security implementations contain the vulnerabilities that mature frameworks have already addressed.

4. Apply Defence in Depth

No single control prevents all attacks. Layer defences: input validation stops injection. Output encoding stops XSS. CSP provides additional XSS protection. WAF provides another detection layer. Each layer catches what the previous one might miss.

5. Keep Dependencies Updated

Automated dependency scanning (SCA) identifies known vulnerabilities in third-party code. Update dependencies regularly. Remove unused packages. Monitor for new CVEs.

6. Test Regularly and Deeply

Annual web application penetration testing at minimum. Test after major releases. Complement automated scanning with manual testing that finds business logic, access control, and chained vulnerabilities scanners miss. Use the web application security testing checklist to verify coverage.

Continuous penetration testing catches vulnerabilities as they're introduced rather than discovering them months later.

7. Train Developers

Developers writing the code are the first line of defence. Security training should be practical, stack-specific, and ongoing. Security champion programmes embed security knowledge within development teams.

8. Implement Security Headers

A one-time configuration providing ongoing browser-level protection. HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy should be standard on every web application.

Web Application Security for Compliance

PCI DSS. Requirement 6 mandates secure development practices addressing web application vulnerabilities. Requirement 6.5 specifically references OWASP Top 10. Requirement 11.3 mandates annual penetration testing. See our PCI DSS penetration testing guide.

SOC 2. Trust Services Criteria CC6 (access controls) and CC7 (system operations) require web applications to prevent unauthorised access and maintain operational security. See how SOC 2 pentests support compliance.

ISO 27001. Annex A.8.25 (Secure Development) and A.8.26 (Application Security Requirements) directly mandate secure web application development and testing. See our ISO 27001 guide.

HIPAA. Web applications processing ePHI must implement access controls, audit logging, and encryption per the HIPAA Security Rule.

For comprehensive compliance alignment, see our penetration testing compliance guide.

How AppSecure Finds and Fixes Web Application Security Vulnerabilities

AppSecure discovers the web application security vulnerabilities that automated scanners miss through expert-led manual penetration testing.

Every Vulnerability Category Covered

Testing covers every vulnerability in this guide: broken access control (IDOR, privilege escalation), injection (SQL, XSS, SSRF, SSTI), authentication and session weaknesses, security misconfigurations, component vulnerabilities, file upload security, business logic flaws, cryptographic failures, and logging gaps. OWASP Top 10 is the starting point, not the finish line.

Business Logic Expertise

AppSecure tests what automated tools cannot: price manipulation, workflow bypass, race conditions, and application-specific abuse. Testers understand your application's intended behaviour and test what happens when that logic is violated.

Zero False Positives

Every finding is validated through exploitation with proof-of-concept evidence. Developers receive confirmed, exploitable vulnerabilities with specific fix guidance for their technology stack.

Fix Guidance That Developers Can Use

Remediation guidance references your specific framework, language, and architecture. Not generic "sanitise input" but specific implementation patterns for your technology stack.

Beyond Web Applications

Web application testing integrates with API testing, mobile testing, cloud testing, and network testing. Application security assessment and offensive security testing provide end-to-end validation.

3-Week Delivery

Standard engagements deliver within three weeks. 90-day remediation support and complimentary retesting. PTaaS provides ongoing testing as your application evolves.

Ready for web application security testing that finds what scanners miss?

Contact AppSecure:

• Schedule Web Application Testing
• Application Security Assessment
• Web Application Security Testing Checklist

Frequently Asked Questions

1. What are the most common web application security vulnerabilities?

The most common web application security vulnerabilities are broken access control (IDOR, privilege escalation), injection flaws (SQL injection, XSS, SSRF), authentication and session management weaknesses, security misconfigurations (verbose errors, missing headers, default credentials), vulnerable components (outdated libraries with known CVEs), insecure file uploads, business logic flaws (price manipulation, workflow bypass), cryptographic failures (weak hashing, missing encryption), and insufficient logging. Broken access control is consistently the most frequently discovered and most impactful category.

2. How do web application security vulnerabilities get exploited?

Attackers exploit web application vulnerabilities by sending requests the developer didn't anticipate. They modify object IDs in URLs to access other users' data (IDOR). They inject SQL syntax into form fields to extract database contents. They submit JavaScript through input fields that executes in other users' browsers (XSS). They call API endpoints directly, bypassing frontend restrictions. They manipulate business parameters (prices, quantities, workflow steps) through modified HTTP requests. Exploitation targets the gap between what the developer intended and what the application actually accepts.

3. What is the OWASP Top 10?

The OWASP Top 10 is a standard awareness document listing the ten most critical web application security risk categories: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Authentication Failures, Software Integrity Failures, Logging Failures, and SSRF. Updated periodically (most recent: 2021), the OWASP Top 10 provides baseline coverage for web application security testing. Professional penetration testing covers OWASP Top 10 and goes beyond into business logic, application-specific, and chained vulnerabilities.

4. Can automated scanners find all web application vulnerabilities?

No. Automated scanners effectively detect injection patterns (SQL injection, reflected XSS), security misconfigurations (missing headers, verbose errors), known component vulnerabilities (CVE matching), and some cryptographic issues. Scanners cannot detect broken access control (IDOR requires understanding data ownership), business logic flaws (requires understanding intended workflows), complex authentication bypasses, or chained vulnerabilities. The highest-impact findings in web application security testing consistently require manual expert testing.

5. What is the difference between web application security testing and penetration testing?

Web application security testing is the broader category encompassing automated scanning, code review, and manual testing of web applications. Penetration testing specifically involves expert testers actively exploiting vulnerabilities with proof-of-concept evidence. Penetration testing is the deepest form of web application security testing, focusing on exploitation validation and business impact demonstration. A web application security assessment might include automated scanning plus manual penetration testing for comprehensive coverage.

6. How often should web application security testing be conducted?

Annual web application penetration testing satisfies most compliance requirements. Testing should also occur before major releases introducing new functionality, after significant code changes affecting authentication or authorisation, after framework or platform migrations, and after security incidents. Applications processing sensitive data (financial, health, PII) warrant semi-annual or quarterly testing. High-velocity development teams benefit from continuous testing through PTaaS.

7. What are web application security best practices?

Core web application security best practices include validating all input server-side, using parameterised queries for all database interactions, applying context-aware output encoding, implementing security headers (HSTS, CSP, X-Frame-Options), using established security frameworks rather than custom implementations, keeping dependencies updated, enforcing authentication and authorisation on every request, encrypting sensitive data in transit and at rest, logging security events, and conducting regular penetration testing.

8. How do I fix broken access control?

Implement server-side authorisation on every request, verifying the requesting user is authorised to access the specific resource. Don't rely on UI hiding to enforce access. Use indirect object references instead of exposing database IDs. Implement deny-by-default access control. Centralise authorisation logic in shared middleware. Test access control through manual penetration testing because automated scanners cannot reliably detect IDOR and authorisation bypass vulnerabilities.

9. What is the business impact of web application security vulnerabilities?

Web application security vulnerabilities enable data breaches exposing customer information (regulatory fines, lawsuits, reputational damage), financial fraud through business logic exploitation (direct monetary loss), service disruption through injection or denial-of-service attacks (revenue loss), and compliance violations (PCI DSS, HIPAA, SOC 2 penalties). Average data breach costs reached $4.88 million globally in 2024. Web application vulnerabilities are the leading cause of data breaches because web applications are internet-facing by design, accept user input, and connect to databases containing sensitive information.

10. How do developers prevent web application security vulnerabilities?

Developers prevent vulnerabilities through secure coding practices: parameterised queries (preventing injection), context-aware output encoding (preventing XSS), server-side authorisation checks (preventing access control bypass), secure session management (preventing session attacks), input validation (preventing unexpected data processing), and security header implementation. Security training should be stack-specific and practical. Security champion programmes embed security expertise within development teams. Automated security scanning in CI/CD catches issues before deployment. Manual penetration testing validates that development practices produce secure applications.