Types of Web Application Attacks: 10 Common Threats and How They Work

Web applications are a primary target for attackers because they are internet-facing, process untrusted input, handle sensitive data, and provide access to critical business systems.

The attack surface has also changed. Modern applications are assembled from custom code, open-source libraries, frameworks, cloud services, and third-party packages. An attacker may target a coding flaw, exploit a vulnerable dependency, manipulate access controls, or abuse a legitimate application function until it performs an unauthorized action.

This creates a visibility problem for security teams.

A WAF may inspect the request before it reaches the application. An EDR or workload tool may later detect a process launch, file change, or unusual network connection. Neither view necessarily explains what happened between those events inside the application.

Runtime application visibility shows which library, function, request, and call chain caused an action, then helps stop dangerous behavior before exploitation turns into compromise.

This article explains 10 common types of web application attacks, how they work, and why protecting modern applications increasingly requires visibility into what code actually executes in production.

Key Takeaways

• Web applications are frequent targets because they process untrusted input, hold valuable data, and connect to critical services.
• Common attacks include injection, XSS, CSRF, broken access control, authentication attacks, SSRF, security misconfiguration, and vulnerable dependencies.
• Many web attacks manipulate trusted application code rather than delivering recognizable malware.
• WAFs inspect traffic, while EDR and workload tools observe system behavior. Neither always identifies the application execution path connecting the two.
• Runtime application security provides code-level context and can stop dangerous behavior at the point of execution.

Why Web Applications Are Persistent Targets

Web applications attract attackers for three main reasons: they are directly reachable, they hold valuable information, and they operate at a layer where infrastructure controls often lack application context.

Public login pages, APIs, upload functions, search fields, and business workflows all accept input that the application must process. Each input creates an opportunity to test how the application handles unexpected data and whether that data can reach a sensitive function.

The potential rewards are significant. Applications frequently handle payment information, customer records, authentication tokens, intellectual property, and connections to internal systems. A successful exploit may give an attacker access not only to application data, but also to every resource the application is authorized to use.

Many attacks also unfold inside the application’s execution flow. A request may pass through an endpoint, framework, middleware component, open-source package, and several internal functions before reaching a sensitive operation. Without runtime application visibility, security teams may see the initial request and the resulting infrastructure activity without seeing the code path that connects them.

How OWASP Categorizes Web Application Risk

The OWASP Top 10 is the industry reference for the most critical web application security risks. OWASP updates the list periodically using real-world vulnerability data, security research, and practitioner input to reflect how application risk is changing.

The current version is the OWASP Top 10:2025. Because the categories and rankings evolve, writers and security teams should verify the latest list directly at owasp.org/www-project-top-ten before relying on older guidance.

The 2025 categories are:

1. Broken Access Control  
2. Security Misconfiguration  
3. Software Supply Chain Failures  
4. Cryptographic Failures  
5. Injection  
6. Insecure Design  
7. Authentication Failures  
8. Software or Data Integrity Failures  
9. Security Logging and Alerting Failures  
10. Mishandling of Exceptional Conditions

The 2025 edition reflects how application risk is expanding beyond isolated coding flaws. Software Supply Chain Failures now ranks third, while Server-Side Request Forgery is included within Broken Access Control. Mishandling of Exceptional Conditions is also a new category covering unsafe error handling, failing open, resource exhaustion, and insecure application states.

These categories describe broad classes of weakness rather than individual attack techniques. SQL injection, command injection, and cross-site scripting all map to Injection, but they target different interpreters and execution environments. CSRF and SSRF map to Broken Access Control, even though they operate through different mechanisms.

This article therefore organizes risks by attack mechanism rather than OWASP ranking. That structure makes it easier to see how attacks relate to one another mechanically, where they operate, and what the application does after receiving attacker-controlled input.

That distinction is increasingly important as the industrialization of exploitation allows attackers to automate reconnaissance, adapt payloads, and move more quickly from vulnerability discovery to active exploitation.

1. SQL Injection

SQL injection occurs when attacker-controlled input is incorporated into a database query without sufficient parameterization or validation.

For example, an application may construct a login query by joining a username and password directly into a SQL statement. A specially crafted value can change the meaning of that query, allowing an attacker to bypass authentication, read records, modify data, or delete information.

Similar risks can appear in NoSQL queries, object-relational mapping layers, and other database interfaces when input is incorporated into query logic unsafely.

The strongest protections include parameterized queries, prepared statements, safe framework APIs, strict input handling, and least-privilege database accounts. WAF rules may block familiar SQL injection strings, but encoded or application-specific variants can evade traffic-level detection.

Runtime context adds another layer by showing which request reached the database operation and which application function constructed the unsafe query.

2. Command Injection

Command injection occurs when untrusted input reaches an operating system command, shell, or process-execution function.

Applications may legitimately invoke system utilities to resize images, process documents, run scripts, or perform other server-side tasks. If attacker-controlled input is inserted into the command without strict validation, the attacker may introduce additional commands or shell syntax.

A successful attack can lead to remote code execution, file access, process creation, credential theft, lateral movement, or a reverse shell.

The request itself may not appear obviously malicious. The danger becomes clear only when the input reaches the function that constructs and executes the command.

Applications should avoid invoking shells with user input whenever possible and use safe APIs, strict allowlists, parameter separation, and minimal runtime privileges. Runtime prevention can provide another safeguard by stopping an unexpected command-execution path before the command runs.

3. Cross-Site Scripting

Cross-site scripting, or XSS, occurs when an application delivers attacker-controlled script content to another user’s browser.

The browser treats the script as if it came from the trusted application. It may then read page content, capture input, modify the interface, redirect the user, steal session information, or perform actions through the victim’s account.

The main forms are:

• Reflected XSS, where malicious input is returned immediately in a response
• Stored XSS, where the payload is saved and later delivered to other users
• DOM-based XSS, where client-side JavaScript processes untrusted data unsafely

Preventing XSS requires contextual output encoding, safe templating, appropriate input handling, Content Security Policy, and avoiding unsafe DOM APIs.

Because XSS executes in the browser rather than on the application server, it requires a different prevention model from server-side command or SQL injection.

4. Cross-Site Request Forgery

Cross-site request forgery, or CSRF, tricks an authenticated user’s browser into submitting an unwanted request.

The attacker does not necessarily need the user’s password. Instead, the attacker relies on the browser automatically including an active session cookie or credential when it sends the request.

A successful CSRF attack may change account details, initiate a transfer, add an administrative user, or perform another action available through the victim’s session.

Protections include anti-CSRF tokens, SameSite cookie settings, origin validation, reauthentication for sensitive actions, and avoiding state changes through GET requests.

XSS and CSRF are related to browser trust, but they are different. XSS injects code into a trusted page, while CSRF abuses an existing authenticated session to submit an unintended action.

5. Broken Access Control

Broken access control occurs when an application fails to enforce what authenticated users are allowed to view or do. This can allow attackers to access another user’s data, perform unauthorized actions, or escalate from a standard account to a more privileged role.

One of the most common forms is an Insecure Direct Object Reference, or IDOR. An application might use a URL such as /accounts/12345 or an API parameter containing a record ID. If the server does not verify that the current user is authorized to access that object, an attacker may change the identifier and retrieve another customer’s information.

Broken access control can also enable horizontal privilege escalation, where one user accesses another user’s resources, and vertical privilege escalation, where a lower-privileged user gains administrative capabilities.

Broken access control has ranked first on the OWASP Top 10 since 2021, reflecting how often authorization failures appear in real applications and how serious the impact can be.

Effective mitigation requires server-side authorization checks on every sensitive request, deny-by-default access policies, consistent ownership validation, and audit logging for access-control decisions and violations. Client-side restrictions are not security boundaries. Hiding a button or route does not prevent an attacker from calling the underlying endpoint directly.

Understanding the relationship between vulnerabilities and exploits is important here. The missing authorization check is the vulnerability. Changing the object identifier to access another user’s record is the exploit.

6. Authentication and Credential Attacks

Authentication attacks target the controls used to verify identity and maintain trusted sessions.

Credential stuffing uses usernames and passwords stolen from other breaches. Brute-force attacks repeatedly test potential credentials, while password spraying uses a small number of common passwords across many accounts.

Attackers may also manipulate session tokens, exploit weak password-reset workflows, abuse improperly validated JSON Web Tokens, or take advantage of sessions that remain active after logout.

Defenses include multifactor authentication, rate limiting, secure session management, breached-password detection, account lockout policies, and strict token validation.

Authentication establishes identity, but authorization must still be checked for every sensitive action. A valid session should never be treated as unlimited access.

7. Security Misconfiguration

Security misconfiguration occurs when applications, frameworks, servers, cloud resources, containers, or deployment systems use unsafe defaults or expose unnecessary functionality.

Common examples include:

• Default credentials
• Exposed administrative interfaces
• Verbose error messages
• Debugging features enabled in production
• Weak security headers
• Overly permissive cloud roles
• Directory listings
• Unrestricted network access

A single configuration problem may reveal sensitive information or expose a service that was never intended to be public. Several smaller weaknesses may also be chained together into a larger compromise.

Secure defaults, infrastructure-as-code scanning, deployment validation, least privilege, and continuous production checks can reduce this risk. Security teams should verify what is actually running because a policy in a repository may not match the live configuration.

8. Vulnerable and Outdated Components

Modern applications depend on large numbers of open-source libraries, frameworks, and transitive dependencies. A vulnerability in one component can expose every application that loads the affected code.

Once exploit details become public, attackers may begin scanning for vulnerable systems quickly. Security teams must then identify where the package is deployed, whether the vulnerable function is used, which team owns the service, and whether an upgrade can be released safely.

Traditional SCA provides valuable package inventory and identifies known vulnerabilities. However, package presence alone does not establish immediate production exposure.

A dependency may exist in an image without ever loading. Another may be active inside an internet-facing application, with the vulnerable function directly reachable through a request.

Runtime SCA helps distinguish those conditions by showing which components are loaded and which vulnerable functions are reachable or executing. This allows teams to focus remediation on meaningful production exposure rather than treating every package finding as equally urgent.

9. Server-Side Request Forgery

Server-side request forgery, or SSRF, occurs when an attacker causes a server-side application to send a request to an unintended destination.

Applications often retrieve URLs to generate previews, process webhooks, import content, download files, or connect to third-party services. If users can influence the destination, an attacker may direct the application toward internal systems.

Potential targets include internal APIs, administrative interfaces, cloud metadata endpoints, databases, and services that trust traffic from the application network.

The resulting connection originates from the legitimate application, so it may resemble normal service-to-service communication. The important context is which request, library, and function caused the connection.

Protections include strict destination allowlists, careful URL parsing, blocking access to internal and metadata address ranges, network segmentation, and minimal application permissions. Runtime application visibility can trace an unexpected outbound request to the exact code path that initiated it.

10. Software Supply Chain Attacks

Software supply chain attacks compromise the systems, packages, and processes used to build and deliver applications.

An attacker may publish a malicious package with a name similar to a legitimate dependency, compromise a maintainer account, take over an abandoned project, alter a build process, inject code into a CI/CD pipeline, or distribute a poisoned software update.

Dependency confusion is one example. An attacker publishes a public package using the same name as an internal dependency and manipulates the build system into downloading the attacker-controlled version.

Malicious packages may execute during installation, build, import, application startup, or only when a particular function is called. Some continue to provide the expected functionality, making harmful behavior difficult to identify during routine testing.

Package signing, dependency pinning, registry controls, build isolation, code review, and software bills of materials can reduce supply chain risk. Runtime monitoring adds another layer by validating how dependencies behave after deployment.

A trusted delivery path should not automatically make every runtime action trustworthy.

The Execution Gap Across Web Application Attacks

WAFs inspect HTTP and HTTPS traffic at the application boundary and apply rules based on known signatures, payload patterns, request attributes, and traffic behavior. This can block many familiar attacks before they reach the application, but it does not provide full visibility into what happens after a request is accepted.

Novel injection variants may use encoding, obfuscation, alternate syntax, or application-specific payloads that do not match an existing rule. Blind attacks may trigger a vulnerable function without producing an obvious response. Logic-based attacks such as IDOR and CSRF may use valid routes, authenticated sessions, and ordinary-looking parameters rather than recognizable malicious payloads.

The limitation extends beyond individual bypass techniques. Raven reports that approximately 70% of real-world attacks have no published CVE, which means there may be no established vulnerability signature, known indicator, or predefined WAF rule to match. Signature-based detection is therefore structurally insufficient for a large portion of the threat landscape.

Across all ten attack types, the most important behavior may occur after traffic passes the perimeter. A request reaches an application route, moves through frameworks and open-source libraries, invokes a function, and produces a process, file, database, or network action. WAFs see the request, while EDR and workload tools may see the resulting system event. Neither view necessarily explains the execution path between them.

This is the execution gap. Protecting internet-facing applications requires visibility into what the application actually does after it accepts a request, especially when the attack looks legitimate at the traffic layer.

Beyond Perimeter Security: Stopping Attacks at Execution

Preventing web application attacks requires multiple layers.

Secure development, SAST, SCA, code review, and testing help identify weaknesses before release. WAFs filter suspicious traffic. Identity controls restrict access. EDR and cloud workload security monitor infrastructure activity.

Runtime application security adds visibility and protection inside the running application.

Behavior-Based Runtime Prevention

Behavior-based runtime prevention monitors actual execution inside the running application. It observes how requests move through libraries, functions, and call chains, then connects that execution to sensitive actions such as command execution, process creation, file access, and outbound network connections.

This context matters because the same low-level action may be legitimate or malicious depending on how it was triggered. An approved application workflow may intentionally launch a child process. The same process launch may indicate exploitation when an attacker-controlled request reaches a vulnerable function through an unexpected call chain.

Unlike signature-based controls, runtime application prevention does not depend entirely on a known payload, published CVE, or existing detection rule. It evaluates execution behavior inside the application and can stop the action before malicious code runs, a process launches, or an exploit-driven connection leaves the workload. This extends protection to zero-days and no-CVE attacks that perimeter rules may not recognize.

Raven applies this model with less than 0.2% CPU overhead when all modules are active. Its sensor is deployed through a Helm chart and supports managed Kubernetes environments including AWS EKS, Google GKE, and Microsoft Azure AKS. Raven’s deployment documentation shows a single Helm install command for the sensor after the required repository and configuration steps are complete.

This combination of application execution context and runtime enforcement helps cover attacks that appear normal at the HTTP layer but behave abnormally once code begins to run.

Where Raven Fits

Raven provides application runtime visibility and prevention inside production applications.

Raven Runtime ADR traces suspicious behavior to the exact library, function, request, and call chain responsible. It connects the application event to the process, container, image, node, and workload so security teams can understand both the code-level cause and the surrounding infrastructure activity.

Raven Runtime SCA shows which open-source components are present, loaded, reachable, and executing. This helps teams distinguish package inventory from active production exposure and prioritize the vulnerabilities that matter most.

Raven Runtime Prevention stops dangerous application behavior at execution, whether the attack is tied to a known CVE, a zero-day, or a CVE-less exploit path.

This approach complements WAF, EDR, SCA, and cloud security controls. Those tools provide important coverage around the application, while Raven fills the gap between accepted input and the code that ultimately executes.

Understanding Web Application Attacks Requires Understanding Execution

Injection attacks manipulate the boundary between untrusted data and an interpreter. XSS and CSRF exploit browser trust. Broken access control and authentication attacks target identity and permissions. Misconfiguration and vulnerable dependencies create paths to exploitation. SSRF and supply chain attacks abuse trusted server and software relationships.

WAFs can reduce the number of malicious requests that reach an application, but they cannot eliminate every application-layer attack. EDR can detect suspicious workload behavior, but it may not identify the application code responsible. SCA can find vulnerable packages, but package presence alone does not prove that vulnerable code is active and reachable.

Runtime application security provides the missing execution context.

By showing which library, function, request, and call chain produced an action, security teams can move from a generic alert to the application-level cause. Runtime prevention can then stop malicious behavior before exploitation becomes compromised.

See how Raven stops web application attacks at execution, before exploits cause damage.