In the OWASP Core Rule Set, what attacker requests does paranoia level 2 catch that PL1 lets through, and what does that cost?
answer
- a dial on rule strictness, not block strength
- every rule carries a level tag
- looser fit catches more and matches more
- PL1 default, PL4 rarely survives production
- breakage lands on someone else's route
basics
~20 sEvery Core Rule Set rule carries a paranoia-level tag, and the configured level decides which rules run at all. PL2 adds looser-fitting rules that catch obfuscated payloads PL1 misses, and those same rules match legitimate requests too.
solid answer
~50 sThe Core Rule Set tags each rule with a paranoia level from 1 to 4, and the level you configure selects which rules are eligible to run. PL1 holds the high-confidence rules that almost never match ordinary traffic. PL2 and above add rules that fit more loosely, so they catch the encoded, padded or unusually shaped payloads an attacker sends specifically to slip past the tight PL1 patterns. The important correction: raising the level does not make blocking harsher. It changes which rules can contribute to the anomaly score, and nothing else. The bill lands in three places at once: legitimate requests broken on routes the platform team does not own, more CPU per request as more rules and more regular expressions run, and a per-route exclusion list that grows with every level you climb.
go deeper
Be ready to say that the level selects which rules run, that higher levels use looser patterns, and that looser patterns also match real user input. Naming PL1 as the default is expected.
Explain why looser rules exist at all - an attacker reshapes a payload until the tight pattern no longer describes it - and be able to separate the level from the threshold as two independent settings.
Show how you would move a shared tier up a level without breaking anyone: measure in a non-enforcing mode first, count refused legitimate requests per route, and take that number to the owners before enforcing.
Own the argument that a level is a purchase, not a posture. Be ready to say which routes justify a higher level, what the fleet-wide raise would cost in capacity and broken flows, and why a quietly un-enforced high level is worse than an enforced low one.
## The dial, stated precisely The OWASP Core Rule Set is a generic rule set: it is written without any knowledge of the applications it will sit in front of, and it therefore cannot know that one team's `description` field legitimately contains angle brackets and quote marks while another team's never does. The paranoia level is how that ignorance is made adjustable. Every rule in the set is tagged with the lowest paranoia level at which it becomes active. You configure one number, 1 to 4. Rules tagged at or below that number run; rules tagged above it do not. PL1 is the shipped default. - **PL1** is the set of rules that match patterns which essentially never appear in ordinary user input. High confidence, low yield. - **PL2** adds rules that fit more loosely. They match shapes that *usually* mean an attack but *sometimes* mean a user pasting rich text, a base64 blob, a code snippet into a support ticket, or a JSON body with a word like `select` in a product description. - **PL3** goes considerably further, matching on generic character classes and structural oddities. - **PL4** is deliberately extreme and is generally only survivable on narrow, well-understood routes with a large hand-built exclusion list. ## What the adversary is doing, and why looser rules exist at all A tight rule is a precise description of one payload shape. An attacker who can read the rule set - and it is public - does not need to defeat the idea behind the rule; they need to send something the pattern does not literally describe. Splitting a token across an encoding, padding with comment syntax, changing the character set, moving the payload from a query parameter into a body the tight rule never inspects: each of these produces a request that is still an attack and is no longer that pattern. The higher paranoia levels are the rule set's answer to that. They stop describing the payload and start describing the *shape* - unusual character mixes, nesting depth, encodings that a browser would never produce for this field. That is strictly more powerful against evasion, and it is strictly worse at telling attackers from users, because the shape is not exclusive to attackers. The two properties are the same property. ## What raising the level does not do Three wrong answers show up constantly, and an interviewer is usually fishing for one of them: 1. **It does not change block strength.** In the Core Rule Set's default anomaly-scoring mode, whether a request is refused is decided by the total anomaly score against a threshold. That threshold is a separate setting. Moving PL1 to PL2 makes more rules eligible to add score; it does not change what the score is compared to, and it does not change the response returned. 2. **PL4 is not strictly better security.** It is a different point on a trade curve. A level so noisy that the operator quietly moves the engine into logging-only mode, or accumulates a hundred blanket exclusions, protects less than a PL1 deployment that is genuinely enforcing. 3. **False positives are not a bug at the higher levels; they are the price.** A rule that fits loosely is doing what it was written to do when it matches a legitimate rich-text field. Treating each one as a defect to be reported upstream misreads the design. ## Who actually pays On a shared ingress tier in front of dozens of teams' routes, the decision and the consequence sit with different people. The platform team sets one number for everyone. The cost arrives as a checkout flow that returns 403 for the subset of customers whose address line contains an apostrophe, and it arrives at the team that owns checkout, who did not choose the level and cannot change it. There are three distinct bills: | Cost | Who feels it | | --- | --- | | Legitimate requests refused | The route owner, in lost transactions | | CPU per request, and the replica count it forces | The platform team's capacity line | | An exclusion list that grows with the level | Whoever maintains the shared configuration | ## Moving a level without an outage The safe sequence is to measure before enforcing. Run the higher level's rules so that their matches are recorded without contributing to the blocking decision - the rule set supports evaluating rules above the enforced level for logging purposes, and the engine itself supports a detection-only mode - then count, per route, how many real requests would have been refused and which fields caused it. That count is the number you take to the route owners, and it is the number that decides whether the level is worth having on that route at all. Choosing a level for the whole tier from a document rather than from your own traffic is how a paranoia raise becomes an incident.
- Does raising the paranoia level change what happens when a request is refused?No. In anomaly-scoring mode the refusal is decided by the accumulated score against the inbound anomaly threshold, and both the threshold and the response are separate settings. The paranoia level only decides which rules are eligible to run and add score. Conflating the two is the most common misreading, and it leads people to raise the level when what they actually wanted was a different threshold.
- Why is paranoia level 4 rarely run across a shared tier?PL4 rules match on generic structural properties of a request, so on real traffic they match constantly. Surviving it means a large, hand-built, per-route exclusion list, which is only affordable on a handful of narrow routes whose input shape you fully control. Applied to dozens of teams' routes it produces either a wave of broken flows or, worse, an operator who quietly stops enforcing.
- On a shared ingress tier, who chooses the level and who feels it?The platform team chooses one number for the whole tier; the route owners absorb the refused requests. That split is the reason paranoia is an organisational argument and not just a configuration value: the person with the dial has no visibility of the broken checkout, and the person with the broken checkout has no access to the dial.
It is the difference between a bouncer who turns away people on a named list and one who turns away anyone who looks like trouble. The second catches more troublemakers and more accountants on a night out.
saying these in an interview costs you the question
- Says a higher paranoia level blocks more aggressively
- Treats PL4 as strictly better security than PL1
- Calls every false positive at PL2 a defect rather than the price
- Confuses the paranoia level with the anomaly score threshold
- Assumes the platform team feels the broken requests it causes