Application and Web Security: The Complete Guide

On 21 February 2025, a small number of signers at the crypto exchange Bybit confirmed what appeared to be a normal transaction between two of their own wallets. The signers were presented with the correct addresses, the correct amounts and everything else was seemingly in place.  But it wasn‘t real. Weeks before, malware operators working in conjunction with North Korea‘s Lazarus Group had secretly gained access to a single developer‘s computer, used as part of the multisig platform Bybit depended upon, through back dooring its Safe {Wallet} application, then loaded the signing window itself with malicious JavaScript. The signers didn‘t fall prey to an aggressive phishing campaign or a weak, guessable password. They were tricked by their own trusted software, rewritten in front of them. By the time anyone noticed, roughly $1.5 billion in Ethereum was gone — the largest theft in the history of cryptocurrency.

Nothing about that attack touched a firewall, a router, or a VPN. It happened entirely inside the application layer: a compromised build pipeline, a trusted developer workstation, and a piece of front-end code that lied to the people using it. That’s the story this guide is really about. Application and web security is the discipline that decides whether your code, your APIs, and the software you didn’t even write yourself can be trusted — and in 2026, that discipline looks very different than it did even three years ago.

In this guide, we will take you from the true beginning of application security, to the end of network security; introduce you to what has shifted in the reimagined OWASP Top 10:2025; expose why your existing firewalls can‘t detect the attacks that matter most and teach you how to create a verifiable not just aspirational security program using the OWASP ASVS 5.0.

Who this guide is for:  Developers, security teams, IT leaders, and business owners looking for a pragmatic take on application and web security from the basics of web defenses to emerging API, cloud-native, AI, and software supply-chain vulnerabilities.

Table of Contents

• Application and Web Security in Simple Terms
• Mapping the Boundaries: Network vs. Web vs. Application vs. Mobile Security
• The Realigned OWASP Top 10:2025
• The API Authorization Gap: Why WAFs Are Blind and WAAP Takes Over
• Beyond Awareness: Operationalizing OWASP ASVS 5.0
• The Framework Ecosystem: ASVS, NIST, ISO, and CIS
• Emerging Attack Surfaces: AI, LLMs, and MCP
• Securing Cloud-Native and Ephemeral Workloads
• Modernizing Identity: NIST SP 800-63B Rev. 4
• Verification and Testing Orchestration: SAST, DAST, IAST, RASP
• Browser-Side Defense in Depth
• Building Your Application and Web Security Strategy: A Roadmap
• Application and Web Security Best Practices
• FAQs
• Bringing It All Together

Application and Web Security in Simple Terms

Application and web security is the practice of making sure the software you build — and the software you depend on — does only what it’s supposed to do, for only the people it’s supposed to do it for.

Picture an online checkout page. Here‘s what it consists of. The customer types in a card number, the page communicates with a payment API, the API communicates with a database, and then a confirmation e-mail is sent to the customer. Application and web security is all of the anything that preserves the integrity of that chain:  ensuring the checkout page can‘t be fooled into executing someone else‘s script,  ensuring the payment API can‘t be called by someone spoofing the identity of a different customer,  ensuring the database can‘t be accessed by anyone who didn‘t first walk through the front door, and ensuring that if any one of those steps fails that it‘s done so securely instead of leaking out information or accidentally giving someone access.

Much more simple said than done.  But the real challenge is on the scope: one product of today is not a single application but dozens, if not hundreds, of micro services, third-party libraries, CI/CD processes and APIs coexisting and inter-operating constantly with only an occasional human overseeing the activities.

Mapping the Boundaries: Network vs. Web vs. Application vs. Mobile Security

One of the most common — and most expensive — mistakes in security planning is treating “security” as one undifferentiated budget line. Network security, web security, application security, and mobile security solve different problems, and a control that’s excellent in one layer does nothing in another.

If you want the deeper mechanics of the network layer specifically — firewalls, VPNs, zero trust, and where the classic “perimeter” still holds up in a cloud-first world — our Network Security guide covers that ground in detail. What matters here is the boundary: a network security team can guarantee that only encrypted, authenticated traffic reaches your application — and still have no idea that the application itself will hand over another customer’s invoice because nobody checked whether the logged-in user actually owned the invoice ID in the URL. That’s not a network failure. That’s an application failure, and no firewall rule fixes it.

Mobile is worth calling out separately because the trust model inverts. A web application‘s server-side code never leaves your infrastructure; a mobile app’s binary ships to a device you don’t control, sitting on hardware an attacker can decompile, patch, and re-sign at leisure. That’s why mobile-specific controls — binary obfuscation, jailbreak/root detection, hardware-backed key storage — exist as a category of their own rather than just “application security on a smaller screen.”

Web Security Fundamentals: TLS, DNS, and Classic Injection Risks

Before getting into what changed in 2025 and 2026, it’s worth being concrete about the fundamentals that haven’t gone anywhere — because a surprising number of incidents still start here, not in some exotic new attack class.

TLS/SSL setup.  All externally-facing services should be configured to use up-to-date TLS (1.2 at the very least, 1.3 recommended), and certificates should be actively watched for expiry and automatic renewal having been arranged. An expired certificate isn‘t merely a shamefaced browser warning:  a fallen certificate,  or one configured incorrectly,  is one of the most common,  completely avoidable, sources of unscheduled downtime,  and man-in-the-middle attack on dilapidated channels.

DNS security. DNS is trusted by almost everything and secured by comparatively few teams. Two failure modes account for most real incidents: subdomain takeover, where a DNS record still points to a decommissioned cloud resource (an old S3 bucket, a deleted Heroku app) that an attacker can claim and serve malicious content from under your own domain, and missing DNSSEC or CAA records, which leaves the door open for DNS spoofing and unauthorized certificate issuance respectively. Both are cheap to fix and commonly missed during routine cleanup — decommissioning a service should always include an audit of the DNS records that pointed at it.

Classic injection — still very much alive. Cross-Site Scripting (XSS) and SQL Injection (SQLi) have made every OWASP list since the 2003 first edition of the project, and they are still right there in the 2025 list‘s Injection category for exactly the same reason:  they keep going out the door into production,  and usually (always, if the best practice is followed) for the same root problem untrusted input to an interpreter (a browser‘s DOM, a SQL engine,  and a shell) with no encoding or parameterization at hand. The longstanding solution hasn‘t changed:  write parameterized queries or use an ORM rather than string-concatenated SQL, and use your framework‘s existing output encoding rather than doing your own escaping for anything thrown back to a browser. Cross-Site Request Forgery (CSRF) completes the non-Basics package blocked with anti-CSRF tokens and the Same Site cookie attribute to come later in this article.

A common answer is that these fundamentals are important even in a report about 2025–6:  we‘re building in a more advanced risk classification below the new upper ‘A’ level on the basis that they are already sound. An organization still shipping SQL injection has little use for an ASVS Level 3 conversation about WebRTC hardening.

The Realigned OWASP Top 10:2025

Under the title “the OWASP Top 10”, for 4 years, it has been the 2021 edition. That changed in November 2025 when OWASP launched the 10:2025 Top 10 – the first revision since 2021, and one of the more significant in the project‘s history.  Comprising an analysis of around 175,000 CVE records mapped against 589 Common Weakness Enumerations, plus a community poll of professionals on the front lines.

The headline shift has as much philosophical significance as it does technical: the 2025 list pulls further toward the root causes end of the spectrum. Two categories are new, one is folded into another, and the overall message is that structural failures — how software is configured, built, and delivered — now outweigh isolated coding mistakes as the dominant source of risk.

Source: OWASP Top 10:2025, owasp.org/Top10/2025

Two of these categories deserve a closer look, because they’re the ones most existing security programs are least prepared for.

A03: Software Supply Chain Failures — the smallest category with the biggest teeth

A03 has only 5 mapped CWEs — the fewest of any category in the entire list — and yet it carries the highest average exploit and impact severity, and it was voted a top concern by the community survey despite limited hard testing data. OWASP’s own framing is candid about why: this is a category where testing tooling hasn’t caught up to the actual risk, so the CVE record understates how dangerous it is.

Three incidents make the case better than any abstract description:

• SolarWinds (2019). Attackers actually infected the build environment and introduced a backdoor in the piece of official, digitally-signed software update transforming trust into access at some 18,000 downstream enterprises.
• The Bybit heist (2025). As described above, attackers didn’t touch Bybit’s own infrastructure at all. They compromised a Safe{Wallet} developer’s machine, hijacked AWS session tokens to get around MFA, and injected malicious JavaScript into the signing interface for a narrow, two-day window — costing $1.5 billion.
• Shai-Hulud (2025–2026). The first confirmed self-propagating worm in the npm ecosystem. It harvested credentials from CI/CD environments and developer machines, then used stolen npm tokens to automatically republish malicious versions of every other package a compromised maintainer controlled — spreading without any further attacker input. A second wave in November 2025 executed during package pre-install (before a developer’s own security tooling could react) and, in some documented variants, threatened to destroy data if credential theft failed.

The common thread across all three: none of them were “vulnerable code” in the traditional sense. They were failures of trust in the pipeline that builds and ships the code.

What actually reduces this risk?

• Maintain a live Software Bill of Materials (SBOM) — For example,  tools like OWASP Dependency-Track, keeps track of all the direct and transitive dependencies, not only the direct ones that you have imported.
• Apply least privilege to build servers. No single person or service account should be able to push to production unreviewed.
• Sign artifacts and pin dependencies by cryptographic hash rather than version string, using provenance tooling such as Sigstore.
• Treat developer workstations as part of the production attack surface. MFA and endpoint monitoring on developer laptops isn’t optional overhead — it’s where several of the largest breaches of 2025 actually started.

A10: Mishandling of Exceptional Conditions — the new #1 concern nobody’s testing for

A10 is brand new, carries 24 mapped CWEs, and — notably — 50% of community survey respondents named it their single top emerging concern, the highest consensus of any category on the list. It addresses what happens when your application encounters something it didn’t expect: a timeout, a malformed input, a downstream service that’s down.

The fix is architectural, not a single patch: build for fail-closed, not fail-open. In practice that means wrapping multi-step transactions in database scopes that automatically roll back on interruption, backing local try/catch blocks with a global exception handler as a last line of defense, and — critically — returning generic error messages to users while logging full technical detail only to private, access-controlled logs.

The API Authorization Gap: Why WAFs Are Blind and WAAP Takes Over

Much of the last twenty odd years of security tooling around the web was designed to identify client-to-server browser traffic: a malicious <script> tag, a’ OR 1=1– added to a form field.  That‘s still worth defending against, but it no longer represents the greatest area of expansion. According to the 2026 API ThreatStats Report, APIs accounted for 17% of all published security vulnerabilities in 2025, and 43% of newly added CISA Known Exploited Vulnerabilities were API-related.

The reason a traditional signature-based Web Application Firewall (WAF) struggles here is structural, not a tuning problem: an API attack using Broken Object Level Authorization (BOLA) — OWASP’s #1-ranked API risk — looks completely legitimate at the packet level. The request is authenticated. The syntax in valid.  The only issue is the user that made the request for /api/invoices/48213 doesn‘t own invoice 48213 and this isn‘t obvious in the request. A WAF built to spot malformed syntax has nothing to flag.

This is the gap that pushed the market from WAF toward WAAP (Web Application and API Protection) — Gartner retired the standalone WAF category back in 2021 in favor of WAAP, and by 2025 had folded that further into its current “Cloud Web Application and API Protection” market guide. A genuine WAAP platform combines four capabilities that a legacy WAF alone doesn’t have:

1. Web application firewall — the classic signature and rule-based layer, still useful for known attack patterns.
2. DDoS mitigation — protecting availability at scale.
3. API threat protection — Schema validation and behavioral baselining that is able to detect attacks that are syntactically correct but semanticallyicious.
4. Bot management — Difficult to distinguish legitimate automation, such as crawling, from credential-stuffing and scraping bots.
5. Ability to separate real automated traffic from credential-stuffing and scraping bots.

Remediating BOLA specifically requires object-level checks that no perimeter tool can perform for you: enforce row-level security so a query for invoice data is automatically scoped to the requesting user’s own records, and perform that authorization check at both the API gateway and again inside the microservice itself — a single point of validation is a single point of failure. If your team is still relying primarily on firewall-based perimeter controls to catch this class of attack, it’s worth an honest audit of what those rules can and can’t actually see.

The shadow API problem. None of this matters if a WAAP platform is only inspecting the APIs your team remembers documenting. “Shadow APIs” — endpoints spun up during a sprint, left behind after a feature was deprecated, or exposed by a third-party integration nobody tracked — are consistently one of the largest gaps in API security programs, precisely because you can’t protect what you don’t know exists. Automated, ongoing API discovery (the majority of WAAP platforms offer this) is just as important as the rules built on top of it; any rate-limiting policy on your documented endpoints achieves nothing to protect the staging endpoint someone failed to decommission.

Beyond Awareness: Operationalizing OWASP ASVS 5.0

Here’s a distinction that trips up a surprising number of otherwise mature security programs: the OWASP Top 10 is not a compliance standard. It’s explicitly a community-consensus awareness document — a prioritized list of what’s most dangerous, not a testable checklist of what “secure” means for your specific application. It defines no verification levels and offers no pass/fail criteria.

The document that actually does that job is the OWASP Application Security Verification Standard (ASVS), and version 5.0 — launched live on stage at Global AppSec EU Barcelona on May 30, 2025 — is the current benchmark. It‘s useful to mention that ASVS 5.0 has itself progressed fast since introducing it: it initially shipped with 14 chapters in May 2025, and by midway 2026 OWASP had reorganized into 17 chapters and approximately 350 individual requirements,  separating Web Frontend Security (V3), Self-Contained Tokens (V9) and OAuth and OIDC (V10) into its own chapters and bringing through WebRTC (V17) into a brand new chapter- a reflection on how fundamental token-based Authentication and dynamic real-time communications are to today‘s application architecture.  Remember to check asvs.dev in case the canonical structure has moved on.

The current chapter lay the groundwork for the following: Encoding and Sanitization, Validation and Business Logic, Web Frontend Security, API and Web Service, File Handling, Authentication, Session Management, Authorization, Self-Contained Tokens, OAuth and OIDC, Cryptography, Secure Communication, Configuration, Data Protection, Secure Coding and Architecture, Security Logging and Error Handling, and WebRTC.

ASVS organizes requirements into three cumulative verification levels:

• Level 1 (Basic Hygiene): The floor for any application handling non-sensitive data. Notably, this is the only level where every requirement can realistically be verified through automated SAST/DAST tooling alone.
• Level 2 (Standard Enterprise): OWASP’s recommended target for most business applications — anything touching PII, financial data, or sensitive business logic. It requires manual code review and logical validation, not just scanner output.
• Level 3 (Critical Infrastructure): Intended for systems in which a breach would be disastrous payment gateways, medical systems, and infrastructure. It requires real modular separation, and a truly layered approach verified by hand.

For an organization currently relying on Top 10 awareness alone, the practical migration path is: pick the ASVS level that matches your data sensitivity (Level 2 for most production business applications), assign explicit chapter ownership across frontend, API, and platform teams so nobody assumes someone else is covering OAuth or session management, and treat the resulting requirement set as your actual acceptance criteria — not a document that lives in a wiki nobody opens.

ASVS and Regulatory Drivers: PCI DSS 4.0.1 and the EU Cyber Resilience Act

Verification standards stop being an internal engineering preference the moment a regulator starts asking for evidence, and two deadlines make this concrete right now.

PCI DSS 4.0.1‘s “future-dated” requirements became fully mandatory on March 31, 2025 — no grace period remains. Two are directly relevant here: Requirement 6.3.2 requires a maintained inventory of custom and third-party software components (functionally, an SBOM for anything in your cardholder data environment), and Requirements 6.4.3 and 11.6.1 require monitoring and integrity-checking scripts loaded on payment pages — a direct, regulatory answer to the exact class of attack that hit Bybit’s signing interface, just applied to checkout pages instead of crypto wallets.

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is the broader, newer driver. It entered into force in December 2024, and its first binding teeth arrive on September 11, 2026 — a mandatory 24-hour early warning and fuller reporting obligation for actively exploited vulnerabilities and severe incidents in any product with digital elements sold into the EU. Full essential-requirements enforcement, including secure-by-design obligations, follows on December 11, 2027. If your product touches the EU market at all, that first reporting deadline is close enough that “we’ll get to it” is no longer a viable plan.

The practical link back to ASVS: mapping your ASVS chapter coverage against these obligations now — rather than during an incident — is what turns “we take security seriously” into an actual audit trail.

The Framework Ecosystem: ASVS, NIST, ISO, and CIS

ASVS isn’t the only framework in this space, and it’s not meant to replace the others — each answers a different question for a different audience.

A helpful mental model: NIST CSF and ISO 27034 attempt to answer ‘is our program mature?’ at the governance level, CIS Controls attempts to answer ‘what is the minimum we should do with limited resources?’, and ASVS answers ‘is this individual application really up to standard?’ Mature AppSec programs will typically use CSF or ISO reporting to the board, with ASVS as the everyday engineering metric.

Application and Web Security for Startups, Growing Teams, and Enterprises

None of the frameworks above assume you’re starting with a dedicated AppSec team, and the right starting point looks very different depending on where you are.

The trap small teams tend to walk into isn‘t skipping security it‘s trying to do enterprise tooling (a full RASP deployment, ASVS Level 3 everywhere) before they get the fundamentals down and using up valuable engineering time on something that doesn‘t actually reduce the attack surface in ways that matter. A five person startup with parameterized queries, dependency scanning, and no hardcoded secrets is significantly more secure than a fifty-person one with an insanely expensive WAAP subscription sitting in front of code trusting client supplied object IDs.

The flip side of this is that larger organizations often make the mistake of thinking a framework written on paper (indicated in a policy document as ASVS PDF, a SAST tool installed but not mandate as a merge gate) equates to controls that have been verified. It isn’t, and it’s exactly the gap the Software Supply Chain Failures and Mishandling of Exceptional Conditions categories above were added to call out.

Emerging Attack Surfaces: AI, LLMs, and MCP

Generative AI adoption and the rise of the Model Context Protocol (MCP) — the emerging standard that lets AI agents call external tools and data sources — have opened attack surfaces that didn’t exist in the 2021 threat model at all. This shows up in two distinct places: the code AI writes, and the actions AI takes.

When AI Writes the Code: The “Vibe-Coding” Security Gap

By 2026, a substantial share of new code on platforms like GitHub is AI-generated, and the security research on what that code actually looks like is not encouraging. Veracode tested over 100 large language models across 80 coding tasks spanning Java, Python, C#, and JavaScript, and found that 45% of AI-generated code samples introduced known OWASP Top 10 vulnerability classes — a rate that hasn’t meaningfully improved across repeated testing cycles. Separate analysis from CodeRabbit found AI-generated pull requests carry roughly 2.74 times the vulnerability density of human-written ones, and Georgia Tech’s Vibe Security Radar project — tracking CVEs directly attributable to AI coding tools — went from 6 confirmed cases in January 2026 to 35 in March 2026 alone.

The incidents aren’t hypothetical. CVE-2025-48757 traced back to an AI app-building platform generating backend database schemas without row-level security enabled by default, exposing roughly 170 production applications’ worth of data. A separate widely reported incident exposed over a million authentication tokens and tens of thousands of email addresses because AI-generated API endpoints returned data without checking whether the requester was authorized to see it — which is to say, the same object-level authorization failure covered in the BOLA section above, just introduced by a model instead of a person.

One practical for a 2026 AppSec program: AI-authored code should be subject to exactly the same level of inspection and validation as code written by even the least experienced member of your team.  In practice it is going to be the same. Be aware that this will involve a fait accompli if you include automated code reviews as part of your process and do not require explicitly granted human consent (as discussed below) for everything from database schemas to access-control annotations, and do not let AI-guided program construction run faster than the CI/CD security gates I would recommend later in this guide.

For example, at the model layer, the OWASP Top 10 for LLM Applications has; Prompt Injection (LLM01) when a harmful prompt inserted into a document, webpage, or tool output tricks the model into doing something it otherwise wouldn‘t, as well as Excessive Agency (LLM03), when an AI agent executes a major operation transferring money, changing infrastructure, deleting data without prompts being approved by a human first.

Finally, on the protocol layer, OWASP‘s more recent MCP Top 10 (still in beta, issued as MCP01:2025 through MCP10:2025) begins to list agent-specific threats, which are defined as risks that pertain to agents that invoke tools ‘dynamically at runtime’ rather than with a ‘hardcoded’ toolset:

• MCP01 — Token Mismanagement & Secret Exposure: hard-coded credentials or long-lived tokens sitting in model memory or protocol logs, retrievable through prompt injection.
• MCP03 — Tool Poisoning: Malicious code disguised as part of a tool‘s description, parameter schema, or return value, which the agent perceives as instruction rather than data.  This was achieved by security researchers at Invariant Labs in April 2025, and a live example of this was observed in June of that year, when it was used to embed and smuggle out data from a corrupted support-ticket process.
• MCP05 — Command Injection and Execution: shell commands executed directly from untrusted model output The classic example is a CVSS 9.6 vulnerability in the popular mcp-remote package(CVE-2025-6514) which had been downloaded over 437,000 times before disclosure.

The practical takeaway for engineering teams: every MCP server your agents connect to is a new trust boundary outside your own codebase, and tool descriptions and outputs need to be treated as untrusted input — the same discipline you’d apply to any other externally supplied data, just applied to a new interface.

Securing Cloud-Native and Ephemeral Workloads

Serverless functions and containerized workloads don’t have a traditional perimeter to defend — the security boundary shifts almost entirely to identity and access management (IAM) and to validating what triggers the function in the first place.

A few patterns matter most in practice:

• Enforce function-level IAM, not account-level. Any Lambda that has to access a single S3 bucket should not be granted a role that allows writing to every other S3 bucket in the account. Wildcard permissions are by far the biggest contributor to blast-radius growth in server less failures.
• Validate event payloads against a strict schema before processing. A function triggered by an S3 notification or a queue message should treat that payload with the same suspicion as a public HTTP request — malicious JSON injected into an event source can trigger unintended downstream commands.
• Set concurrency quotas and execution timeouts. Cloud elasticity is a feature until an attacker exploits it: triggering repeated, resource-heavy invocations without proper limits can produce a Denial of Wallet attack — no data is stolen, but the compute bill becomes the damage.
• Watch response-streaming limits. Newer serverless capabilities that support larger streamed responses (some platforms now support responses up to 200MB) meaningfully raise the ceiling on how much data a single compromised function can exfiltrate in one call — a detail worth reviewing in your platform’s current configuration rather than assuming legacy limits still apply.

If your cloud footprint spans multiple providers or a hybrid architecture, this connects directly to broader posture questions — our Cloud Security guide covers the wider infrastructure picture this section assumes.

Modernizing Identity: NIST SP 800-63B Rev. 4

Application security doesn’t stop at code — how your application handles authentication is squarely in scope, and the federal baseline changed meaningfully in 2025. In later 2025, NIST officially published Special Publication 800-63B Revision 4. It reverses a good portion of the passwords best practices recommended for the longest time:

• Length over complexity. NIST now recommends a minimum of 15 characters when a password is the only authentication factor, and explicitly prohibits mandatory character-class rules (forced symbols, numbers, mixed case) — research showed these rules produced more predictable, not less predictable, passwords.
• No more scheduled rotation. Forced periodic password changes are now discouraged outright; a password should only be changed when there’s evidence it’s been compromised.
• Mandatory breach screening. New passwords should be checked against blocklists of known-compromised credentials at creation time, not just at login.
• Formal recognition of passkeys. Synced passkeys are recognized at AAL2, device-bound passkeys at AAL3 — a signal that phishing-resistant authentication is now the expected direction, not an optional upgrade.

If your application‘s password policy is still mandating 90-day rotations or require special characters, then you are behind the curve on the government standard and increasingly the compliance standards that cite it.

Verification and Testing Orchestration: SAST, DAST, IAST, RASP

And yes, you need to keep velocity in a CI/CD environment without losing rigor, through a lot of lean layers of testing because each testing methodology sees a different slice of the problem.

None of these substitutes for the others. SAST and SCA catch problems before code ships; DAST and IAST catch what only shows up when the application is actually running; RASP is the safety net for whatever gets through everything upstream of it. A pipeline that only runs SAST at commit time has excellent visibility into code quality and zero visibility into whether the deployed configuration is actually secure.

Browser-Side Defense in Depth

Even with the API and backend hardened, the browser remains an active attack surface, and a handful of controls carry a disproportionate share of the defense:

• Secure cookie attributes. Session cookies should set HttpOnly (blocking JavaScript access, closing off a major XSS exfiltration path), Secure (transmit only over HTTPS), and an appropriate SameSite value to limit cross-site request forgery.
• Content Security Policy (CSP). A properly scoped CSP header restricts which script sources a page will execute at all, turning a successful injection into a much smaller problem.
• HSTS (HTTP Strict Transport Security). Forces browsers to connect over HTTPS to only your domain, closing window for downgrade and man-in-the-middle attacks on first request.
• Session lifecycle management. Sessions should expire on inactivity, rotate their identifier on privilege change (like login), and be fully invalidated server-side on logout — not just cleared from the client.
• CORS configured explicitly, never with a wildcard alongside credentials. A Cross-Origin Resource Sharing policy that reflects any requesting origin back as allowed — especially combined with Access-Control-Allow-Credentials: true — effectively disables the same-origin protection the browser was trying to give you. List allowed origins explicitly.
• Subresource Integrity (SRI) on third-party scripts. Any script loaded from a CDN or third-party host should carry an SRI hash, so the browser refuses to execute it if the file changes unexpectedly — the same class of attack that let malicious JavaScript reach Bybit’s signers in the first place, applied at the browser layer instead of the build layer.

These map directly onto ASVS’s Web Frontend Security and Session Management chapters, which is a useful way to think about this layer: it isn’t a separate checklist, it’s the verifiable, testable expression of “browser security” inside the same framework covering everything else in this guide.

When Prevention Fails: Responding to an Application Security Incident

Every control in this guide cuts risk; none eliminate it, and a team‘s response in the first hours after something goes wrong can make the difference between a one-paragraph issue notice and a front-page story. A few tenets are more important than any one tool:

• Have a kill switch for API keys, tokens, and third-party integrations that doesn’t require a full deployment. Bybit’s incident, the Shai-Hulud worm, and the Lovable/Supabase exposure all shared one trait: the window between compromise and detection was the multiplier on damage. Being able to revoke credentials and disable an integration in minutes, not hours, matters more than almost any preventive control.
• Preserve logs before you start remediating. The instinct to immediately patch and redeploy is understandable and often destroys the evidence needed to understand scope — how far did the compromise actually spread, and which customers were affected.
• Assume the blast radius is larger than the first finding suggests, particularly for supply-chain-style incidents. A compromised dependency or build server rarely affects only the one application where it was first noticed.
• Have a pre-drafted, honest customer communication template. The organizations that come out of a public incident with their reputation intact are consistently the ones that disclosed clearly and early, not the ones that minimized or delayed.

None of this replaces the prevention work covered throughout this guide — but a security program that’s never rehearsed its response to a real incident is, in practice, a security program that’s untested exactly where it matters most.

Building Your Application and Web Security Strategy: A Roadmap

Turning everything above into an actual program is a sequencing problem more than a technology problem.

1. Inventory the real attack surface. Catalog every application, API, serverless function, and third-party dependency — including the ones nobody remembers deploying. You can‘t prove something you don‘t know exists.
2. Pick your ASVS target level per application. Not everything needs Level 3. Match level to data sensitivity: Level 1 for low-risk internal only tools, Level 2 as the fall back for anything that comes near customer/financial data, Level 3 for those few systems where one breach would be catastrophic.
3. Build automated security gates into CI/CD. SAST and SCA at commit and build time, with builds blocked on high-severity findings — not just flagged for later review.
4. Add dynamic and runtime layers. DAST or fuzz testing against staging, IAST during QA, and RASP in production as the final backstop against zero-days.
5. Generate and monitor an SBOM continuously. Treat it as a living artifact, not a one-time audit deliverable — new transitive dependencies show up between releases, not just at them.
6. Establish fail-closed exception handling as a coding standard, not a per-team preference — global exception handlers, generic user-facing errors, detailed logs kept private.
7. Measure Mean Time to Remediate (MTTR) and vulnerability escape rate, and report both up to engineering leadership. What gets measured is what gets fixed before the next audit rather than during the next incident.

Application and Web Security Best Practices

1. Validate authorization at the object level, every time — not just whether a user is logged in, but whether they specifically own the resource they’re requesting. This single check would have prevented most of the BOLA incidents covered in this guide.
2. Treat every third-party dependency as part of your attack surface, including transitive ones your team never directly imported and AI-generated code your team didn’t manually write line-by-line.
3. Fail closed by default. An error, timeout, or unexpected condition should deny access and halt the transaction, not silently grant access or continue in an undefined state.
4. Return generic errors to users; log full detail privately. Stack traces, database schema hints, and internal file paths are reconnaissance data in the wrong hands.
5. Enforce least privilege on build systems and service accounts, not just human user accounts — CI/CD pipelines are now a more attractive target than the applications they deploy.
6. Pin and sign dependencies rather than trusting version ranges alone, using provenance tooling so a tampered package can’t silently pass as legitimate.
7. Use ASVS Level 2 as your starting point for anything that manages sensitive or regulated data, with Level 1 strictly reserved for very low risk internal utilities and Level 3 for the handful of systems that would be catastrophic if compromised.
8. Run SAST/SCA at commit time and DAST/IAST before release — Gear up the testing so that each step each attempt to find what the others structural don’t sees.
9. Set IAM scopes clearly for each server less function and repeatedly check for wildcard policies, rather than just at immediate Launch.
10. Mandate the removal of password rotation & complexity rules and implement the NIST current recommendations; length, blocklist screening, phishing resistant MFA.
11. Configure the CORS, CSP and cookie attributes explicitly, in a security-conscious way, rather than relying on“framework defaults” driven by considerations of convenience.
12. Rehearse your incident response before you need it — a credential-revocation and communication plan that’s only ever existed on paper adds delay exactly when speed matters most.

FAQs

Q1: What’s the real difference between web application security and network security?

A: Network security is infrastructure-centric – keeping data moving through large areas of network segments such as firewalls, routers and IPS’s; all are below the application layer. Application security is code-centric – applying security to custom application logic, micro services, databases, APIs that no mere network controls can interpret.  An authenticated API request asking for a data element outside its permissions is an application question.

Q2: How is Web Application and API Protection (WAAP) different from a traditional WAF?

A: A WAF in the old days was a nose-over-shoulder inline proxy that would block attack patterns we all know and fear SQLi, Cross Site Scripting using mostly static firewall rules,  optimized for client-to-server (browser) traffic. WAAP is the cloud-delivered evolution that brings DDoS, API-specific–schema-mitigations, bot management, and more to the WAF experience in order to catch those machine-to-machine, logic-abuse attacks which are, on the surface, only a syntactical approval.

Q3: Why isn’t the OWASP Top 10 considered a full security standard?

A: It’s explicitly a community-consensus awareness document that highlights the most critical risks based on survey data and CVE analysis — it sets no granular technical requirements and defines no verification levels an auditor can check off one by one. For a testable, requirement-by-requirement baseline, organizations use OWASP ASVS instead.

Q4: Which OWASP ASVS level should my application target?
A: Level 1 covers basic hygiene for low-risk applications and can be verified almost entirely with automated tooling. Level 2 — OWASP’s recommended default for most business applications handling PII or financial data — requires manual code review alongside automation. Level 3: Critical infrastructure, services and data. Those levels serve critical infrastructure and critical data/services, so that if they are breached it would be a disaster for the whole organization. It also needs a modular separation of parts and a thorough defense-in-depth.

Q5: How do SAST, DAST, IAST, and RASP fit together?
A: They look at different points in the lifecycle and at different blind spots: SAST looks at the source code proactively in build stage for structural flaws; DAST looks at a target app interactively from outside in staging for environment/configuration flaws; IAST looks at a target app introspectively interactively in QA for gray-box flaws; RASP looks at a target app proactively in production for exploits on deployed app. A full pipeline performs all four instead of waiting for them to be interchangeable.

Q6: Does AI-generated code need different security testing than code written by developers?

A: Not different tooling, but different assumptions. The identical SAST, SCA, and code review gates are still relevant, but they need to execute without exception studies by Veracode and others have shown that AI-driven source code produces OWASP Top 10 class vulnerabilities at a significantly higher frequency than human programmers, especially with respect to default access-control parameters and object-level permissions. Consider AI-proposed database schemas and permission frameworks as requiring hard human approval instead of accepting defaults.

Q7: Do we still need a WAAP if our cloud provider already offers built-in security features?
A: Usually yes, for a specific reason: most built-in cloud security features are strong on infrastructure-level protection (network ACLs, basic DDoS absorption) but weak or absent on the API-specific and business-logic threats — schema validation, behavioral bot detection, object-level authorization abuse — that dedicated WAAP platforms are built around. The cloud-native controls and WAAP are not overlapping they‘re protecting a different level of the same stack.

Bringing It All Together

The through-line across every section of this guide is the same one the Bybit heist illustrated at the top: the perimeter was never the whole picture, and in 2026 it’s an increasingly small part of it. A network firewall can be flawless and still let through a request that’s perfectly valid at every network layer and catastrophically wrong at the application layer — the wrong user reading the wrong invoice, a build server trusting a compromised dependency, a server less function processing an event payload nobody validated.

That‘s why the change from just being aware of OWASP Top 10 issues to actually verify them in the application as part of the ASVS is just as important as having a new list of potential vulnerabilities.  And, it is equally as powerful to know that Software Supply Chain Failures and Mishandling of Exceptional Conditions are front and center in that list. Being able to prove — with a testable requirement and a passing result — that your specific application actually defends against them is the difference between a security program and a security aspiration.

None of the individual pieces here — WAAP, ASVS, SBOMs, fail-closed exception handling, modern identity guidance — does the whole job alone. The companies sustaining through actual breaches in 2026 will be those managing application security as an ongoing, continuous verification actvity that occurs during development,  rather than as a once-a-year list retaken after the OWASP list changes once again.

Related Reading

• WordPress Security Guide
• What Is a Web Application?
• Cross-Site Scripting (XSS)
• Dynamic Application Security Testing (DAST)
• Penetration Testing
• Vulnerability Assessment vs. Penetration Testing
• The Evolution of WAFs

• Network Security: The Complete Guide to Protecting Modern Infrastructure
• Cloud Security: The Complete Guide for 2026
• Data Security and Privacy: The Complete 2026 Guide
• Data Security Compliance Guide
• The Role of Firewalls in a Security Strategy

Sources & References

1. OWASP — Top 10:2025, including category structure, CWE counts, and methodology. owasp.org/Top10/2025
2. OWASP — Application Security Verification Standard (ASVS) 5.0, GitHub repository and release notes. github.com/OWASP/ASVS
3. OWASP — MCP Top 10 (beta), category definitions MCP01–MCP10:2025. owasp.org/www-project-mcp-top-10
4. NIST — SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management. pages.nist.gov/800-63-4/sp800-63b.html
5. BleepingComputer — Bybit / Safe{Wallet} investigation findings, on the developer-workstation compromise and $1.5B theft. bleepingcomputer.com
6. Wiz Research — Shai-Hulud npm Supply Chain Attack analysis. wiz.io/blog/shai-hulud-npm-supply-chain-attack
7. Escape — API ThreatStats Report 2026 findings, on API-related vulnerability and CISA KEV share. escape.tech/blog
8. Gartner market naming context (via Ammune.ai) — evolution from WAF to WAAP to Cloud WAAP market guides. ammune.ai/blog
9. Veracode / CodeRabbit / Georgia Tech Vibe Security Radar — AI-generated code vulnerability research, via Cloud Security Alliance research notes. labs.cloudsecurityalliance.org
10. EU Cyber Resilience Act (Regulation (EU) 2024/2847) — timeline and reporting obligations. cyberresilienceact.eu
11. PCI Security Standards Council — PCI DSS 4.0.1 future-dated requirement deadlines. blog.pcisecuritystandards.org