How do API and web application protection platforms handle zero-day attacks without causing false positives?

They stop zero-day attacks by combining layers: a positive security model that only admits what the API defines as valid, managed rules with anomaly scoring and calibrated thresholds, and virtual patches once the vulnerability is known. They avoid false positives by deploying in log mode, measuring, and tuning with scoped exceptions before blocking.

Why zero-days and false positives pull in opposite directions

NIST defines a zero-day attack as one that exploits a previously unknown hardware, firmware or software vulnerability [1]. By definition, no specific signature exists on day one. A WAAP (web application and API protection) therefore has two ways to stop it:

• Be strict about what it accepts, so the unexpected does not get through even if it is not known.
• Detect generic classes of attack (injection, command execution) rather than specific exploits.

Both ways run the same risk: blocking legitimate traffic. Generic rules, the OWASP CRS documentation warns, know nothing about the services they protect, and legitimate traffic can match a generic attack pattern [2]. The whole craft is raising protection without triggering those false positives.

The four mechanisms

1. Positive security model: what is not defined does not pass

In a positive model you define the valid input and reject whatever does not conform. OWASP's virtual patching guidance describes it as the stronger approach, but manual and hard to scale, and recommends applying it selectively at a specific location [3]. For APIs, the practical equivalent is validating each request against the OpenAPI schema: Cloudflare's documentation explains that the schema defines which requests are valid, that detection does not mitigate on its own, and that results should be reviewed in an analysis before the profile is enforced with custom rules [4].

The practical consequence is that the positive model requires the schema to be current: an API that changes weekly without updating its specification creates false positives of its own.

2. Negative model with anomaly scoring

A managed rule set (such as the OWASP Core Rule Set, CRS) detects attack patterns. The key idea in CRS is that individual rules only detect and add points; they do not block on their own, and blocking depends on an accumulated score against a threshold [5]. By default, the most common inbound threats carry 5 points, and minor violations carry less; with a threshold of 7 several matches are needed, and with 10, at least two critical rules or many lesser ones [5]. Raising the threshold makes the set less sensitive and so less likely to block, at the expense of coverage. The documentation asks you to take into account that each category has a different number of rules (SQL injection has more than 50) [5].

Paranoia levels add more and more aggressive rules: level 1 aims for few or no false positives; higher levels raise the likelihood, and CRS warns that running a high level in blocking mode without tuning is very risky [6]. Other managed WAFs use the same principle: Cloudflare's OWASP set adds each matching rule's score into a cumulative score [7].

3. Virtual patching: concrete protection while the fix arrives

OWASP defines virtual patching as a policy enforcement layer that detects and blocks exploitation attempts against a known flaw without modifying the vulnerable code [3]. It is the answer to a zero-day once it is known. The process it recommends has six phases: preparation, identification, analysis, virtual patch creation, implementation and testing (starting in log-only mode) and follow-up, until it is removed when the real fix ships [3].

Three precautions from the same guidance:

• A virtual patch reduces exposure, it does not remove the vulnerability: the code still has to be fixed.
• Rules that block only the exact payload of the public exploit have limited long-term value.
• Overly broad rules block legitimate transactions, so define in advance how they are monitored and how they are rolled back [3].

To decide what to patch first, it helps to cross-check your inventory against CISA's catalogue of exploited vulnerabilities [8].

4. Context and behaviour layers

Some platforms add reputation, rate limits or machine learning models. Treat them like any vendor claim: ask to measure them with your traffic and check what happens when they are wrong.

Where false positives come from

• Generic rules against legitimate content. The classic CRS example: a field that legitimately contains HTML triggers an XSS rule at paranoia level 2 even though the application handles it safely [2].
• Large request bodies. Cloudflare's documentation warns that they can inflate the OWASP score and cause false positives [7].
• The application framework's own traffic. Forms that invoke server functions, rich text editors, queries with code-like syntax or serialised payloads can look like an attack without being one.
• An outdated schema in the positive model.
• An unsuitable paranoia level or threshold for that route.

Tuning without opening holes: scoped exceptions

CRS is clear: false positives are resolved by writing rule exclusions, not by editing the rules (doing so effectively forks the rule set, and updates would overwrite your changes). And the exclusion should have the narrowest scope possible: a variable, a rule or a tag; runtime exclusions can be limited to a path or other condition. If you run several applications, each exclusion package is enabled only at the location of its application; removing rules entirely is a last resort [2].

Translated into a working policy:

1. An exception has a specific path, parameter and rule; never "disable this rule across the whole site".
2. Every exception carries an owner, a reason and a review date.
3. Exceptions are reviewed and removed when the reason goes away; a forgotten exception is an open door.

Measure before you change

The most neglected part. Before removing an exception (or hardening a rule), we measure first. Here we describe, as methodology only, one practice from our work: before removing a WAF exception, we measure how an OWASP managed rule matches against the application's server-action requests, in log or simulate mode, and decide from that data.

The general procedure:

1. Fix the question: "If I remove this exception, would legitimate traffic be blocked?"
2. Put the rule in log or simulate mode on the affected route, without blocking. AWS WAF documents that the Count action does not terminate evaluation: it counts the request and keeps processing the following rules [9].
3. Observe a representative window, including deployments and the usual business peaks.
4. Analyse the matches: which rule, which route, which parameter, which data matched. CRS logs show the rule ID and the matched data, which explains precisely what caused the match [2].
5. Classify a sample of the matches as legitimate or suspicious.
6. Decide using the table below and record the decision in writing.
7. Change and measure again after deployment.

This way of working avoids two expensive mistakes: raising the global threshold to "switch off" a local false positive, and removing an exception by eye.

Phased rollout

1. Observe: rules in log or count mode.
2. Block the clear cases: paranoia level 1 and default scores, on the most exposed routes.
3. Tune: scoped exceptions, based on data.
4. Raise the bar by route: higher levels only where risk justifies it and there is time to tune.
5. Maintain: review exceptions, virtual patches and coverage periodically. OWASP notes that customising a WAF takes effort that must be maintained as the application changes [10].

A WAAP does not replace secure code: authorisation and logic flaws are fixed in the application (see how to detect vulnerabilities in a SaaS application).

How we help

Hodeitek reviews application and API protection from the attacker's perspective with pentesting and Red Team, helps watch and respond with the managed SOC (SOCaaS / MDR) service and organises evidence and processes with GRC consulting. If you want to know what an attacker sees of your domain, you can ask about places in the external radar. For the intelligence context that feeds these decisions, read what threat intelligence is.

Frequently asked questions

How do API and web application protection platforms handle zero-day attacks without causing false positives?

They combine several layers and stop some of them: those that fit generic attack classes detected by managed rules, those that violate a positive model (such as an API schema) and, once the vulnerability is known, those covered by a virtual patch. False positives are avoided by deploying in log mode first, measuring and tuning with narrowly scoped exceptions before blocking. It is not a guarantee against every attack, which is why OWASP stresses that a virtual patch does not replace fixing the code [3].

What is anomaly scoring?

A mechanism in which each matching rule adds points and blocking depends on the sum reaching a threshold, rather than blocking on a single match [5].

What is the difference between the positive and negative security models?

The positive model defines what is valid and rejects the rest; the negative model blocks known attack patterns. The positive is stronger but more laborious; the negative deploys faster but admits variants that evade it [3].

How do I reduce false positives without lowering my guard?

Measure first in log mode, use exclusions with the narrowest possible scope (route, parameter, rule) and do not edit the rules [2]. Raising the global threshold also reduces false positives, but it does so by lowering sensitivity across the whole site [5].

How long should a rule stay in log mode?

There is no universal figure: long enough to cover the usual traffic cycles and at least one application deployment, and to have a sample of matches to classify.

Next step

Do you want to review how the protection of your applications and APIs is tuned? Let's talk. And remember that your WAF or content delivery provider is a critical third party: HodeiShield helps manage third-party risk and compliance.

Sources

1. Zero-day attack (glossary). NIST CSRC. https://csrc.nist.gov/glossary/term/zero_day_attack
2. False Positives and Tuning. OWASP CRS documentation. https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/
3. Virtual Patching Cheat Sheet. OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html
4. API Shield: Schema validation. Cloudflare documentation. https://developers.cloudflare.com/api-shield/security/schema-validation/
5. Anomaly Scoring. OWASP CRS documentation. https://coreruleset.org/docs/2-how-crs-works/2-1-anomaly_scoring/
6. Paranoia Levels. OWASP CRS documentation. https://coreruleset.org/docs/2-how-crs-works/2-2-paranoia_levels/
7. WAF managed rules. Cloudflare documentation. https://developers.cloudflare.com/waf/managed-rules/
8. Known Exploited Vulnerabilities Catalog. CISA. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
9. How AWS WAF handles rule and rule group actions. AWS documentation. https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-rule-actions.html
10. Web Application Firewall. OWASP Community. https://community.owasp.org/Web_Application_Firewall