Schema-Based Testing Strategies 
¶
A strategy is a reusable scanning recipe used by Schema-Based Testing during Active Scan or Passive Scan. Each strategy targets one vulnerability class and contains the detection logic the engine applies during a run. The set of strategies enabled in a test policy determines which vulnerability classes are checked.
Strategies fall into two categories:
-
Default strategies — provided by Wallarm, kept up to date with new attack patterns, and available to all accounts that have Schema-Based Testing enabled. They cannot be edited, only viewed and toggled per policy.
-
Custom strategies — created by you to extend the engine with checks specific to your application or threat model. A custom strategy is bound to your account and can be enabled in any of your test policies.
Each strategy is either of type Active (sends attack requests during a run) or Passive (analyzes captured traffic only). The strategy's type determines which scan mode it participates in.
Default passive strategies¶
| Strategy | Purpose |
|---|---|
| Data Exposure | Detects unauthorized exposure of sensitive user data, authentication secrets, and third-party credentials in API responses. |
| Security Headers Misconfiguration | Flags missing browser security headers on rendered content and improper cache-control directives on responses carrying sensitive data. |
| Secrets Management | Detects credential-grade secrets transmitted over insecure channels and session cookies set without proper security attributes. |
| Service Internals | Detects exposure of internal server details through debug output, stack traces, version fingerprinting, and unintended static file serving. |
| Web Vulnerabilities | Identifies common web application vulnerabilities through pattern analysis, including open redirects, SSRF, injection syntax, and cross-site scripting markup in request inputs. |
Default active strategies¶
| Strategy | Purpose |
|---|---|
| BOLA (Broken Object Level Authorization) | Checks whether one user can access or modify another user's resources by reusing object identifiers with their own credentials. |
| BFLA (Broken Function Level Authorization) | Verifies whether principals can invoke functions, workflow steps, or management actions reserved for higher-privilege roles or outside their tenant. |
| Business Logic Abuse | Detects flaws that allow attackers to gain unauthorized value, bypass workflow constraints, or manipulate quantities, states, and application-specific invariants. |
| Excessive Data Exposure | Identifies API responses that return sensitive, internal, or unnecessary fields beyond what the client needs. |
| JWT Authentication Flaws | Tests JSON Web Token implementations for algorithm manipulation, signature bypass, claim tampering, weak secret brute-force, missing expiration or audience/issuer validation, and replay of non-revocable tokens. |
| Mass Assignment | Detects APIs that bind all client-supplied fields directly to internal models, allowing unauthorized modification of restricted attributes (for example, roles, status, pricing). |
| NoSQL Injection | Sends operator-based payloads into query-driving fields to bypass authentication, expand result sets, or perform unauthorized data modifications. |
| Resource Exhaustion | Detects missing rate limits, brute-force exposure, and client-controlled amplification that lets attackers degrade availability or scale server-side work via unbounded inputs. |
| SQL Injection | Targets query-driving parameters with SQL syntax payloads to detect authentication bypass, unauthorized data access, data modification, and schema disclosure. |
| SSRF (Server-Side Request Forgery) | Identifies endpoints where user-controlled input can influence backend outbound network requests to attacker-controlled or internal destinations. |
| Unauthenticated Access | Detects endpoints that allow reading, modifying, or deleting business resources without requiring authentication, including cases where predictable selectors make objects directly addressable. |
Browsing strategies¶
Strategies are managed on the Security Testing → Schema-Based → Strategies tab. Use the All / Active / Passive filter to narrow the list. Default strategies are read-only — open one to inspect its description and the vulnerability classes it covers. Custom strategies can be edited and deleted.
Creating a custom strategy¶
To extend the engine with checks specific to your application or threat model:
-
Go to Security Testing → Schema-Based → Strategies and click Create strategy.
-
Provide a Name. The slug is generated automatically; it must be lowercase, may contain digits and underscores, and must not collide with a reserved or already-existing slug.
-
Choose the strategy type:
- Passive — analyzes captured traffic without sending additional requests. Provide the detection logic in the Content field.
- Active — sends targeted requests during the run. Provide the search prompt in the Search content field; the engine uses it to derive hypotheses to test against the application.
-
Save the strategy. It becomes available immediately on the Strategies tab and can be enabled in any new or existing test policy.
Enabling strategies in a policy¶
Open a test policy → Working Modes section. For each mode (Active Scan, Passive Scan), toggle the mode on, click Advanced settings, and select which strategies participate. Disabling a mode disables all of its strategies for that policy.
By default, every strategy of the corresponding type is enabled when you turn on a scan mode. Narrow the selection if you want to focus a policy on a specific class of vulnerabilities, or if a particular check is noisy on your application.