App and API Security
Core concepts
App & API Protector applies a layered rule set to inbound HTTP/S traffic. Know the difference between managed (Kona) rules and custom rules: managed rules are curated and versioned by the vendor with attack categories and a numeric ID, while custom rules are yours to define by hostname, path, method, header, or parameter conditions. Understand rule actions - deny, alert, and the intermediate "slow" or challenge-style mitigations - and how tuning (disabling a rule, adding exceptions/conditions) reduces false positives without weakening coverage.
API protection hinges on API definitions (an imported or auto-discovered schema such as OpenAPI) and the API gateway enforcing positive-security behavior: allowed methods, parameter types, and request-body validation. Learn how rate controls count requests per client (by IP, cookie, header, or a custom key) over a time window and what happens when the threshold trips.
Traps to watch
- Confusing alert-only with deny: an alert logs and passes traffic; it never blocks.
- Assuming a managed rule tuned off for one path is off globally - exceptions are scoped.
- Mixing up positive (schema/allow-list) and negative (signature/pattern) security models.
- Forgetting that API definitions must match the deployed spec, or validation silently passes unknown parameters.
Rule of thumb
Tune from evidence, not fear: run in alert, collect matches, then scope a narrow exception (specific parameter or path) rather than disabling the whole rule. For APIs, prefer positive security - if it is not in the definition, it should not be accepted.
Worked example: A managed SQL-injection rule fires on a search parameter that legitimately contains quotes. Correct fix: add a condition-scoped exception for that parameter/path, not a global rule disable.