7 In-Depth Examples of Web Application Attacks
Updated September 2, 2025
Breaches rarely begin with a cutting-edge exploit. They often come from vulnerabilities in web applications already running in production, like your customer portal, APIs, and content management system. Malicious actors repeatedly find the same weaknesses despite years of OWASP lists, red team exercises, and thousands of innovative tools.
Malware injection remains the leading attack vector, accounting for 34% of all breaches, with incidents up 29% in the past year. Stolen credentials are close behind at 30%, followed by application misconfigurations at 26%. Attackers could use AI-driven methods and complex attack chains, but exploiting well-known, well-documented flaws works just fine.
Sometimes, seeing the reality is the only way to believe it, and that starts with understanding real-world attacks, how they unfolded, and how they could have been prevented.
Why Web Application Attacks Are Getting Worse
The volume and sophistication of web application attacks are growing, but not always in the ways security teams expect. Many breaches exploit the same weaknesses organisations have struggled with for years. As businesses launch more apps, APIs, and integrations, the attack surface expands faster than enterprises can secure it.
Web application security best practices can help, but only if applied consistently across every environment. Here are three of the biggest challenges enterprises face when protecting their web apps:
1. Threats Chain Across Layers
Modern attacks chain low-severity issues into full breach paths. For example, an exposed CI variable might reveal API credentials, which grant access to a cloud role with excessive permissions; that role can then modify security groups or deploy malicious code to a misconfigured public endpoint.
None of these steps in isolation may trigger a critical-severity alert, but chained together, they create a direct, exploitable route to compromise that only becomes visible when you analyze risks as part of the same kill chain.
2. Unmapped Web Routes and Misconfigured APIs
Most products now have several web-facing layers comprising admin panels, partner portals, service APIs, and login flows. These endpoints aren't always documented, rate-limited, or even monitored. A forgotten test route or staging instance pushed to prod can be enough to expose internal functions or sensitive data.
APIs are often the most direct line to that logic. Many APIs bypass frontend checks and go straight to core services. A single unprotected method or improperly scoped token can give attackers direct access to internal business logic, and most scans fail to catch this because they can’t understand both the code and its execution context.
3. AI Is Now Part of the Attack Surface
AI applications (including autonomous AI agents) are being deployed rapidly, often outside the usual software development lifecycle. Without robust AI agent security, these tools can become entry points for attackers. Common risks include unapproved agents running in the background and models downloaded from unverified sources.
97% of AI breaches occurred where no access controls were in place. And most were linked to third-party SaaS AI models with unclear provenance or patching standards.
7 In-Depth Examples of Web Application Attacks
1. Log4Shell (2021–2022)
Type: Remote code execution via JNDI injection
Summary: Multiple flaws in the Log4j 2 logging library, including CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105, allowed remote code execution of arbitrary code by passing crafted strings through log inputs. Exploits persisted across several versions as each patch revealed new bypasses.
What went wrong: Legacy dependency was often hidden in transitive dependencies (teams were unaware they were even using it) and went unpatched in many systems.
What could have helped: An SCA tool with capabilities for deep dependency mapping could have identified the vulnerable and unpatched transitive packages. Runtime posture mapping could have determined whether the vulnerable path is reachable in production.
2. GitHub Secrets Exposure via Public Repos (Ongoing Issue)
Type: Secrets leakage
Summary: Millions of tokens, credentials, and private keys are leaked yearly via public GitHub repositories. These secrets often provide immediate access to infrastructure or user data.
What went wrong: Developers continue to commit secrets accidentally, often relying on private repos or CI/CD tools for protection. Many secrets remain active for years, and 70% of those leaked in 2022 were still valid in 2025.
What could have helped: Tools like Jit can scan pull requests, CI configs, and embedded images for compromised credentials. They flag secrets in real time, assess runtime access risk, and suggest immediate rotation. These combined capabilities could have reduced the exposure window to minutes instead of months.
Automated PR Security for GitHub Repos
Catch vulnerabilities before they merge. Jit integrates directly into GitHub, ensuring security scans run automatically without slowing development.
3. MOVEit Transfer SQL Injection (2023)
Type: SQL injection
Summary: Attackers exploited a flaw in MOVEit’s file transfer platform (CVE-2023-34362) that allowed unauthenticated SQL injection, giving them direct access to backend databases. The breach affected hundreds of organisations globally, from the BBC to US state governments, leading to large-scale data theft.
What went wrong: The vulnerable endpoint accepted user input and passed it straight to the database without proper sanitization or parameterization.
What could have helped: A SAST scanner like Semgrep could have flagged the unsafe database call before the code merged. Combined with deployment pipeline checks, this would have prevented the change from reaching production until fixed.
4. 23andMe Account Takeover (2023)
Type: Credential stuffing
Summary: Attackers reused stolen credentials from past breaches and ran automated credential stuffing attacks to access over 155,000 UK-based 23andMe accounts, scraping sensitive genetic and ancestry data. They then advertised stolen data on hacking forums. The company was fined £2.3M for failure to secure sensitive user data.
What went wrong: The platform lacked basic protections, including no mandatory MFA, rate-limiting, or weak monitoring. Raw DNA information, despite its sensitivity, was accessible without further verification.
What could have helped: A DAST tool like OWASP ZAP could have picked up exposed login pages lacking rate-limiting or MFA requirements. At the same time, runtime monitoring could have flagged scraping activity, allowing for detection and immediate response.
5. Okta Customer Support Portal Breach (2023)
Type: Session hijacking
Summary: Attackers accessed Okta’s support system using a compromised service account, downloading HAR files containing active session tokens. They used these tokens to hijack user sessions and access five customer environments, including Cloudflare and 1Password.
What went wrong: An employee stored the support system’s service account credentials in their personal Google account, where attackers stole them and used them to access the portal. Weak monitoring failed to flag the intrusion quickly, and unbound session tokens stayed valid well after the breach began. Poor segregation between the internal support environment and production systems let the attackers pivot straight into sensitive customer data once inside.
What could have helped: Automated scanning of uploaded files for active tokens could have caught the exposure early. Identity Lifecycle Management tools to automate account provisioning and deprovisioning would have made hijacking much harder.
6. Snowflake Credential Abuse (2024)
Type: Credential theft via public access points
Summary: Threat actors (UNC5537) used stolen credentials from infostealer malware to access hundreds of cloud customer portals tied to Snowflake. They then exfiltrated sensitive data for later extortion.
What went wrong: API keys and logins were compromised and not rotated. In some cases, session timeouts were too long. Several compromises originated from third-party contractor devices infected with infostealer malware, often due to risky personal use, which still had privileged access into customer environments.
What could have helped: A secret scanner in the development pipeline could have caught hardcoded keys before they shipped. Checks for overly broad IAM roles and long-lived sessions, tied to whether those accounts were exposed to the internet, would have clarified which access paths needed to be contained before compromise.
7. Ivanti Zero-Day RCE (2025)
Type: Remote code execution via web admin panel
Summary: A suspected Chinese state-backed group exploited chained zero-days (CVE-2025-4427 and CVE-2025-4428) in Ivanti’s web-based admin tools to gain unauthenticated access. Targets included critical infrastructure and government systems across multiple regions.
What went wrong: Internet-facing admin panels were left exposed, with weak monitoring, hardcoded credentials, and delayed patching. Attackers used this access to extract sensitive user data and authentication tokens.
What could have helped: Platforms that combine infrastructure-as-code scanning with cloud security posture management can highlight exposed admin interfaces or public IPs long before a vulnerability is disclosed.
Best Practices to Prevent Web Application Attacks
Security should begin at the pull request stage and stay linked to the production context. Every change should trigger automated scans for vulnerabilities, dependency risks, and exposed secrets to catch weak points before they combine into a kill chain. For example, an insecure Terraform update might seem minor until paired with an exposed key, as seen in recent multi-step breaches.
Treat CI/CD pipelines as critical assets, as they often hold credentials and control deployment to production. Audit automation code for hardcoded secrets, broad permissions, and unsafe configurations, and enforce policies that prevent build systems from becoming pivot points (a failure that contributed to the Snowflake credential abuse incident).
Validate infrastructure-as-code against the live environment before deployment. This closes the gap between intended and actual posture, helping to prevent overly permissive firewall rules, open ports, or internet-facing services from slipping through.
Correlate these findings with runtime exposure data so you can check for misconfigurations and verify whether they are exploitable in production. A strong alignment between application security and data centre management ensures these controls extend to all physical and virtual infrastructures that support your workloads.
Finally, consolidate results from code, pipeline, infrastructure, and runtime scans into a single backlog. Prioritise using real-world exploitability so teams can focus on changes that reduce risk instead of chasing low-value alerts.
A platform like Jit can support this approach by running these checks in real time. It maps each issue to production risk, correlating results across layers into one prioritised view. It removes the need to juggle multiple tools while keeping security connected from commit to runtime.
Bringing Your Security Layers Together
The incidents covered, from the cascading vulnerabilities in Log4Shell to the credential theft in Snowflake and the session hijacking at Okta, make it clear that web application breaches often succeed because defenders treat each risk in isolation. Unpatched dependencies, stolen credentials, and misconfigured services became stepping stones in multi-stage attack paths. The common thread is that these flaws existed in different stack parts and were never assessed for their combined exploitability.
Jit addresses this exact problem by embedding coordinated security checks directly into development and deployment workflows. It runs SAST, SCA, secrets detection, IaC scanning, and runtime exposure checks in real time, then maps each issue to its potential impact in production.
If a developer commits a credential, the tool can trace which cloud resources it unlocks. If an IaC change weakens a security group, it checks whether the affected service is reachable from the internet. By correlating these signals into a single, prioritised backlog, Jit lets teams act on the few issues that could realistically drive an end-to-end compromise, instead of chasing hundreds of unrelated alerts. Discover more here.
