A policy should express intent without exceeding entitlement
A Web Application Firewall policy translates security intent into request decisions. It defines how managed inspection, scoring, bot controls, rate limits, authentication protections, geographic rules, explicit lists, and protocol constraints behave for a tenant or application. Because it sits in the request path, a mistake can either expose the origin or interrupt legitimate users.
Good policy design begins with a strict boundary: the subscription plan determines which protection layers and limits exist. The policy determines how enabled capabilities treat requests within those limits. A policy must never activate a layer that the plan does not provide, and a user interface toggle must never be the only enforcement point.
This separation keeps commercial entitlement, control-plane configuration, and runtime behavior consistent. Plans are system laws. Policies are operational instructions constrained by those laws.
Understand policy scope and precedence
Vorpcel uses three policy levels in a deterministic order. An application-specific policy has highest precedence. If it does not exist, the tenant-global policy applies. If neither exists, the platform default applies. There is no policy per domain. Domains belong to applications for routing and layer configuration, while the application policy treats requests for that application's domains.
This precedence model supports safe defaults and justified exceptions. The platform default provides usable protection from the beginning. A tenant-global policy reflects organization-wide risk tolerance. An application policy exists only when a specific application needs different behavior.
Absence must remain different from an empty or partially constructed object. Deleting an application policy should restore inheritance from the global or default policy. Creating an application policy by accident can freeze copied values and prevent later global improvements from reaching that application. Interfaces should therefore make inheritance visible and require an explicit decision to override it.
Policy resolution should be testable with the same request context used by the runtime. Operators need to see the effective source, revision, and relevant values. Otherwise a saved policy can appear correct in the portal while a stale or differently scoped policy controls traffic.
Start from a usable default
A default policy should protect a normal application without requiring the customer to understand every field. It should use conservative managed inspection, bounded request sizes, common protocol expectations, practical scoring thresholds, and bot behavior that does not challenge ordinary navigation without evidence.
Defaults should also be internally coherent. Log, challenge, and block thresholds need an intentional order. Rate limits need valid windows and bursts. Authentication controls need sensible route assumptions or remain inactive until configured. A default that contains contradictory thresholds or unsupported layer flags is worse than no default because it creates false confidence.
When a new policy is created, the form and application programming interface should produce the same normalized representation. Validation must cover ranges, enumerations, country codes, address lists, route patterns, header constraints, and relationships between fields. Unknown fields should not silently reach the runtime.
Separate observation from enforcement
Policy rollout should distinguish logging, scoring, challenging, and blocking. Logging records a signal without changing the request. Scoring combines evidence into a risk value. A challenge asks the client to prove browser or session behavior. Blocking stops the request.
Shadow mode is useful during calibration because it suppresses score-based challenge and block decisions while preserving evidence. It is not a universal bypass. Direct controls can remain active, including explicit deny lists, geographic decisions, request-method or body restrictions, direct rules, and rate limits. Operators must understand this boundary before using shadow mode as a safety switch.
Score mode for bot detection is also frequently misunderstood. It means bot evidence contributes to the score rather than producing an unconditional bot action. If the combined score reaches the challenge threshold, the request can still receive a challenge. Setting the relevant threshold to zero can disable that score action where the policy contract defines zero as disabled.
These semantics should be documented next to the fields and verified in runtime tests. A policy name such as score or shadow is not enough; the decision path must define which controls are suppressed and which remain authoritative.
Tune managed inspection with evidence
Managed request inspection identifies common malicious patterns across paths, parameters, headers, and bodies. Sensitivity levels trade broader detection for greater false-positive risk. Begin at the recommended balanced level, observe matched categories and affected routes, and raise sensitivity only with an operational reason.
A false positive should be handled narrowly. Capture the request route, method, parameter location, matched rule category, normalized value, application behavior, and whether the request is authenticated. Prefer a specific exception tied to the smallest valid scope over disabling a protection family for the entire tenant.
Exceptions need owners and review dates. Application behavior changes, and an exclusion created for an old payload can remain long after the original need disappears. The same evidence used to create an exception should be available when deciding whether to remove it.
Do not tune against synthetic attack strings alone. Controlled tests confirm that enforcement exists, but production tuning needs representative legitimate traffic and clearly authorized security testing. The goal is to preserve valid application semantics while rejecting malicious structures.
Design rate controls around resources and identity
A global requests-per-second limit can absorb crude floods, but application abuse is usually route specific. Login, password reset, search, export, checkout, and expensive application programming interface operations have different cost and risk.
Choose a key that matches the threat model. Source address is useful but can combine many users behind a shared network and can be distributed by attackers. Session, token, account, route, and fingerprint signals provide additional context when available. Limits should define a window, threshold, burst behavior, action, and recovery.
Rate controls must also respect plan limits and runtime capacity. A policy cannot request an unlimited configuration where the plan defines a bound. The control plane should reject invalid values before publication, and the runtime should clamp or fail safely if it receives an inconsistent object.
Test rate policy with valid concurrency. A sequential loop may not reproduce a burst. Confirm the exact response action and recovery after the window. Verify that trusted internal integrations have a documented path rather than a permanent broad bypass.
Protect authentication routes as a distinct surface
Authentication endpoints concentrate valuable behavior: credential guessing, stuffing, enumeration, session abuse, and automated account creation. A policy can identify login routes, apply tighter rate and bot analysis, normalize error behavior, and challenge suspicious sessions.
The application still owns authentication correctness. It must use secure password handling, multi-factor authentication where appropriate, session rotation, account recovery controls, authorization, and safe response messages. The Web Application Firewall reduces abusive traffic and adds evidence; it does not become the identity system.
Route definitions need precise matching. An overly broad login pattern can challenge unrelated application programming interface traffic. An incomplete pattern can leave alternate authentication endpoints outside the intended control. Include method, path normalization, and versioned routes in testing.
A staged deployment workflow
- Confirm routing. Verify that permitted requests reach the expected origin through the Web Application Firewall and that direct origin access is constrained where architecture allows.
- Identify the effective policy. Record whether default, tenant-global, or application policy applies.
- Validate the schema. Check every field, range, relationship, and plan entitlement before publication.
- Observe representative traffic. Use logging or shadow behavior to collect matched signals without suppressing direct controls.
- Review false positives. Investigate by route and rule category; create narrow, owned exceptions only where necessary.
- Enable challenge selectively. Start with high-confidence bot or score conditions and confirm completion behavior.
- Enable blocking. Apply thresholds with evidence and monitor decision, latency, origin, and support metrics.
- Re-test inheritance. Delete a temporary application override and confirm that global or default policy resumes.
- Track revisions. Keep the effective revision and publication time visible so stale runtime state can be diagnosed.
How to verify that every field is honored
Policy tests should be table driven. For each field, define a request that should remain allowed and one that should trigger the configured behavior. Cover boundary values, disabled states, malformed input, and interaction with shadow mode. Verify both decision and telemetry.
Precedence tests need three distinguishable policies. Configure different harmless thresholds at default, tenant, and application levels, then prove that the application value wins. Remove it and prove that the tenant value wins. Remove the tenant value and prove fallback to default.
Plan tests must attempt to enable every unavailable layer through both user-facing and direct application programming interface paths. The authoritative service must reject the operation or publish the layer as disabled. Changing policy should never escalate entitlement.
Finally, challenge tests must complete the full flow. Receiving a challenge proves that the edge made a decision, but successful completion and continued request handling prove that session state, verification, and origin forwarding work together.
Limitations
A Web Application Firewall policy cannot understand every business rule, repair insecure code, or guarantee protection from unknown techniques. Encrypted or unsupported traffic outside the inspection path, direct origin access, stale policy distribution, and incomplete routing can reduce coverage.
Shadow and scoring modes can reduce deployment risk but can also create false confidence if operators assume every action is disabled. Exceptions, allow lists, and relaxed thresholds accumulate operational debt. Policy quality depends on monitoring, review, and application knowledge.
Conclusion
A reliable policy is deterministic, constrained by the plan, explicit about precedence, and verifiable field by field. It begins with a usable default, creates application overrides only when justified, separates observation from enforcement, and treats exceptions as maintained security decisions.
The central discipline is simple: plans define what the tenant is entitled to use; policies define how those available controls treat requests. Keeping that boundary intact prevents configuration from becoming privilege escalation and keeps runtime behavior explainable.
Where Vorpcel Fits
Vorpcel provides platform, tenant-global, and application policy levels with deterministic precedence, plan-derived layer enforcement, normalized validation, and runtime decision telemetry. Teams can stage Web Application Firewall behavior, tune specific applications, and inspect the effective result without creating policy at the domain level.