Standard: OWASP Application Security Verification Standard v4.0.3
Target Level: Level 1 (with partial Level 2 coverage)
Self-Assessment Date: February 2026
Product Version: 1.5.x
License: Apache 2.0 (open source core)
Overview
ContractShield is a runtime API security middleware that validates every HTTP request against the application’s OpenAPI contract before it reaches business logic. This document maps ContractShield’s capabilities to specific OWASP ASVS requirements that it helps applications satisfy.
ContractShield does not replace a full ASVS compliance program. It is a security control that addresses specific verification requirements, particularly in input validation, API security, and business logic protection.
ASVS Coverage Summary
| ASVS Chapter | Coverage | Role |
|---|
| V1 — Architecture, Design & Threat Modeling | Partial | Enforces contract-first design |
| V4 — Access Control | Partial | CEL invariants enforce business rules |
| V5 — Validation, Sanitization & Encoding | Strong | Core capability |
| V7 — Error Handling & Logging | Partial | Structured security event logging |
| V8 — Data Protection | Partial | Blocks exfiltration of unexpected fields |
| V12 — Files & Resources | Partial | Path traversal prevention |
| V13 — API & Web Service | Strong | Core capability |
| V14 — Configuration | Partial | Secure defaults, deny-by-default |
V5 — Validation, Sanitization & Encoding
This is ContractShield’s primary domain. Every request is validated against the OpenAPI specification before reaching application code.
| Requirement | Description | Status | How ContractShield addresses it |
|---|
| 5.1.1 | HTTP parameter pollution prevention | ✅ Met | Contract validation rejects parameters not defined in the OpenAPI spec |
| 5.1.2 | Framework mass assignment protections | ✅ Met | Rejects any field not explicitly defined in the request schema — core feature |
| 5.1.3 | Positive validation (allowlisting) | ✅ Met | Allowlist-by-design: only fields defined in the OpenAPI contract are accepted |
| 5.1.4 | Structured data strongly typed and validated | ✅ Met | JSON Schema validation enforces types, formats, patterns, min/max on every field |
| 5.1.5 | URL redirects/forwards to allowlisted destinations | Partial | SSRF detection blocks internal IP ranges and dangerous protocols |
| 5.2.2 | Unstructured data sanitized | Partial | Detects injection patterns in string fields |
| 5.2.4 | SQL injection prevention | ✅ Met | Detects SQL injection patterns; Pro sink-aware RASP traces to database layer |
| 5.2.5 | NoSQL injection prevention | ✅ Met | Detects NoSQL operators ($gt, $ne, $where, etc.) in request payloads |
| 5.2.6 | LDAP injection prevention | Partial | Detects common LDAP injection patterns |
| 5.2.7 | OS command injection prevention | ✅ Met | Detects backticks, $(), pipes, semicolons, &&, || in payloads |
| 5.2.8 | Path traversal prevention | ✅ Met | Detects ../, encoded variants, and absolute path injection |
| 5.3.3 | Output encoding (JSON) | Partial | Enforces response schema compliance (Pro) |
V13 — API & Web Service Security
| Requirement | Description | Status | How ContractShield addresses it |
|---|
| 13.1.1 | All API responses match defined schemas | ✅ Met | Response validation against OpenAPI contract (Pro) |
| 13.1.2 | API schema validation on all input | ✅ Met | Core feature — every request validated against OpenAPI schema |
| 13.1.3 | RESTful API accepts only defined content types | ✅ Met | Content-Type validation against spec |
| 13.1.4 | Authorization checks on all endpoints | Partial | CEL invariants can enforce authorization rules |
| 13.2.1 | Protection against mass assignment | ✅ Met | Rejects fields not in schema — primary defense |
| 13.2.2 | JSON schema validation | ✅ Met | Full JSON Schema draft-07 validation |
| 13.2.5 | RESTful services validate incoming content type | ✅ Met | Validates Content-Type header against spec |
V4 — Access Control
| Requirement | Description | Status | How ContractShield addresses it |
|---|
| 4.1.1 | Trusted enforcement point for access control | Partial | Middleware enforces contract before business logic executes |
| 4.1.2 | Deny by default | ✅ Met | Allowlist model: undefined = denied |
| 4.2.1 | Sensitive data/API protected against IDOR | Partial | BOLA/IDOR auto-detection planned (v1.6); CEL invariants can enforce ownership checks now |
V1 — Architecture, Design & Threat Modeling
| Requirement | Description | Status | How ContractShield addresses it |
|---|
| 1.1.6 | Centralized security controls | ✅ Met | Single middleware enforces policy across all endpoints |
| 1.1.7 | Enforcement of security controls server-side | ✅ Met | All validation is server-side, cannot be bypassed by client |
| 1.5.2 | Input validation approach documented | ✅ Met | OpenAPI spec IS the documentation of validation rules |
V7 — Error Handling & Logging
| Requirement | Description | Status | How ContractShield addresses it |
|---|
| 7.1.1 | Log security-relevant events | ✅ Met | All violations logged with timestamp, method, path, violation type, action taken |
| 7.1.2 | Log all access control failures | ✅ Met | All rejected requests logged with details |
| 7.1.4 | Each log event includes sufficient context | ✅ Met | Structured JSON logs with IP, path, method, violation, mode |
V12 — Files & Resources
| Requirement | Description | Status | How ContractShield addresses it |
|---|
| 12.3.1 | Path traversal prevention | ✅ Met | Detects ../ and encoded path traversal in all string fields |
| 12.3.2 | File paths from user input not directly used | Partial | Blocks path traversal patterns in request payloads |
V14 — Configuration
| Requirement | Description | Status | How ContractShield addresses it |
|---|
| 14.2.1 | Component dependencies up to date | ✅ Met | Automated dependency updates via Dependabot |
| 14.4.1 | Deny unknown HTTP methods | Partial | Validates HTTP method against OpenAPI spec |
Attack Vectors & CWE Mapping
ContractShield provides runtime protection against these attack categories:
| Attack | CWE | OWASP API Top 10 | Detection |
|---|
| Mass Assignment | CWE-915 | API6:2023 | Schema allowlisting — extra fields rejected |
| Prototype Pollution | CWE-1321 | — | Semantic detection of __proto__, constructor, prototype keys |
| SQL Injection | CWE-89 | API8:2023 | Pattern + sink-aware RASP (Pro) |
| NoSQL Injection | CWE-943 | API8:2023 | MongoDB/Mongoose operator detection |
| Command Injection | CWE-78 | API8:2023 | Shell metacharacter detection |
| SSRF | CWE-918 | API7:2023 | Internal IP, localhost, dangerous protocol detection |
| Path Traversal | CWE-22 | API8:2023 | Encoded and raw ../ detection |
| BOLA/IDOR | CWE-639 | API1:2023 | CEL invariants + auto-detection (v1.6) |
| Excessive Data Exposure | CWE-213 | API3:2023 | Response schema enforcement (Pro) |
What ContractShield Does NOT Cover
For a complete ASVS compliance program, these areas require additional controls:
| Area | ASVS Chapter | Recommended Tooling |
|---|
| Authentication | V2 | Your auth framework (Passport, Spring Security, etc.) |
| Session Management | V3 | Your session library + secure defaults |
| Cryptography | V6 | Your TLS termination + encryption libraries |
| File Upload Validation | V12 (partial) | Dedicated file validation + virus scanning |
| Business Logic (complex) | V10 | Application-specific logic + testing |
| Communications | V9 | TLS/mTLS at infrastructure level |
Verification
This self-assessment can be verified by:
- Code review — ContractShield is open source under Apache 2.0
- Testing — Run the included test suite:
npm test / pytest / mvn test
- Penetration testing — We use ContractShield on our own PTaaS platform (ptaas.contractshield.dev) in block mode
- Independent audit — We welcome third-party security assessments
Last updated: February 2026 — ContractShield v1.5.x
