Positive Security Model: allowlist instead of blocklist

The Positive Security Model reverses the logic of classic filters. Instead of recognizing and blocking known attack patterns (blocklist, Negative Security Model), it precisely defines what a valid request must look like; everything else is rejected. To do this, an API fully describes, per endpoint, which fields exist, what type they have, and which format and value ranges are permitted. What isn't in the schema isn't allowed.

The advantage is structural: a blocklist has to know every conceivable attack in advance and fails against new variants and evasion techniques (encoding, splitting, polyglots). An allowlist is robust against unknown input because it isn't looking for the bad, it's letting the good through. In the API world, the specification already provides this allowlist: OpenAPI describes paths, methods, parameters, and bodies, and the individual data structures follow the JSON Schema vocabulary.

Schema enforcement means enforcing this contract document at runtime, not just maintaining it as documentation. Every request is validated against the schema before it reaches the backend code.

AspectPositive Model (allowlist / schema)Negative Model (blocklist / filter)
Core principleOnly let through what's explicitly allowedBlock known attack patterns
Protection against unknown attacksHigh, since non-conforming input is rejectedLow, new variants bypass filters
Maintenance effortSchema must stay current and completeSignatures must be continuously added
Typical implementationOpenAPI / JSON Schema at the gateway and in the serviceWAF signatures, regex blocklists
Protection against mass assignmentYes, via additionalProperties false and readOnlyNo
Protection against BOLA / logic flawsNo, requires authorization logicNo

Positive vs. Negative Security Model in input validation

What gets validated: type, format, length, pattern, enum

JSON Schema provides a precise vocabulary for constraining input. Effective validation combines several layers:

  • Type: type: string, integer, boolean, object, array. An ID expected as a number must not be an object or array.
  • Format and pattern: format: email, format: uuid, format: date-time, as well as regular expressions via pattern. This lets you enforce that an order number really matches a fixed pattern.
  • Length and size: minLength, maxLength for strings, minimum, maximum for numbers, minItems, maxItems for arrays. Length and size limits also cap resource consumption.
  • Enum and constants: enum restricts a field to a fixed set of allowed values, for example a status to ["open", "paid", "cancelled"].
  • Required fields and strictness: required enforces the presence of fields; the decisive setting is additionalProperties: false, which rejects any field not declared. This exact switch is what turns documentation into an allowlist.

Consistently enforced type, format, and pattern checking removes the basis for injection attacks, because special characters, oversized payloads, or structurally foreign values never get through in the first place. Validation doesn't replace parameterized processing in the backend, though; it complements it as an upstream layer.

Preventing mass assignment (relation to BOPLA, API3:2023)

Mass assignment arises when a framework automatically maps incoming JSON fields onto internal object properties (object binding), letting the client set fields not intended for them. If an attacker adds {"role": "admin"} or {"verified": true} when creating an account and the backend accepts these fields unchecked, they escalate their privileges or manipulate internal state.

This pattern belongs to BOPLA (Broken Object Property Level Authorization, API3:2023 in the OWASP API Security Top 10). BOPLA covers two sides: excessive data exposure (the API returns more properties than necessary) and mass assignment (the API accepts more properties than the client should be allowed to set).

Schema enforcement addresses the input side directly. With additionalProperties: false and an explicit property list, unknown or read-only fields are rejected. Fields that should only be read can be marked in OpenAPI with readOnly: true, so they aren't accepted in request bodies. It's important to maintain separate schemas for input and output rather than using the same data model for both directions.

Request and response validation at the gateway

Schema enforcement can be enforced centrally at the API gateway, before requests reach the backend. The gateway loads the OpenAPI definition and validates incoming requests against path, method, parameters, headers, and body. Invalid requests are rejected with 400 Bad Request, without burdening the application code with faulty input.

Response validation is also worthwhile: responses are checked against the defined output schema so that no unwanted or extra fields reach the outside. This limits excessive data exposure even if the backend accidentally serializes too much data. Response validation thus acts as a second line of defense on the BOPLA output side.

Central enforcement has advantages: a single validation point, consistent error responses, and reduced load on the services. But it doesn't replace validation within the services themselves, since not every data flow necessarily runs through the gateway. Security follows the principle of defense in depth: gateway enforcement and server-side validation complement each other. The specification being validated against must also be complete and maintained, otherwise gaps arise from undocumented endpoints (related to Improper Inventory).

Limits: validation doesn't replace authorization checks

The most important limitation: schema enforcement checks the shape of a request, not its authorization. A request that's syntactically and semantically perfectly valid can still be a serious security violation.

The classic example is BOLA (Broken Object Level Authorization, API1:2023). When a user calls GET /accounts/1043, the ID 1043 is a perfectly valid integer within the allowed value range. The schema rightly accepts the request. Whether the requesting user is allowed to access exactly this account is purely an authorization question that only the application logic, with reference to the authenticated context, can answer. Validation sees nothing suspicious here.

The same applies to BFLA (function-level authorization), flawed business logic, and abuse of legitimate flows (business flows). These vulnerabilities are context-dependent and elude purely structural checks. Input validation is therefore a necessary but not sufficient protection layer: it eliminates injection and mass assignment, but authorization, authentication, and logic checks must be correctly implemented independently of it.

Sources

Keep reading
OWASP API Top 10BOPLA: Broken Object Property Level Authorization Attack classInjection in APIs OWASP API Top 10BOLA: Broken Object Level Authorization