perf(appsec): cache negative SQLi RASP evaluations#18704
Draft
florentinl wants to merge 1 commit into
Draft
Conversation
Contributor
|
Codeowners resolved as |
BenchmarksBenchmark execution time: 2026-06-26 11:53:10 Comparing candidate commit 93cfd4d in PR branch Found 0 performance improvements and 3 performance regressions! Performance is the same for 81 metrics, 0 unstable metrics. scenario:iast_aspects-re_expand_aspect
scenario:iast_aspects-re_match_noaspect
scenario:iastaspectsospath-ospathbasename_aspect
|
florentinl
added
the
changelog/no-changelog
florentinl
force-pushed
the
codex/appsec-sqli-rasp-cache-poc
branch
5 times, most recently
from
f28fea8 to
10e550f
Compare
Introduces RaspSqliCache, a per-request negative cache for SQLi RASP evaluations. Repeated identical queries in one request skip WAF subcontext allocation entirely on cache hit. Design choices: - Cache key is (hash(sql), db_system): uses hash() instead of the sql string reference to avoid holding query strings in memory for the request lifetime. Python's SipHash-1-3 with a 128-bit random seed makes adversarial collisions infeasible; accidental collision probability at 128 entries is ~4e-16 per request. - Invalidation is event-driven: the cache is cleared whenever the processor sends a new persistent address to the WAF main context (rule_type is None branch in _waf_action), since the WAF subcontext inherits main context data and previously-cached results may not hold. - Max 128 entries per request; only clean results (return_code==0, no data/actions/timeout/meta) are cached. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
florentinl
force-pushed
the
codex/appsec-sqli-rasp-cache-poc
branch
from
10e550f to
93cfd4d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
SQLi RASP checks run on every instrumented DB call. ORM-heavy endpoints trigger many identical queries per request (N+1 patterns, repeated lookups) — each previously ran a full libddwaf subcontext evaluation.
This PR adds a request-local negative-result cache for SQLi RASP. When the WAF returns a clean result for a `(sql_statement, db_system, persistent_addresses_snapshot)` triple, subsequent identical evaluations within the same request skip subcontext creation and WAF execution.
Cache safety:
SQLi-only for now; other RASP types lack the same high-frequency repeated-call pattern.
Testing
Three new unit tests in `tests/appsec/appsec/test_processor.py`:
Risks
Cache correctness depends on WAF determinism for a given `(sql, db_system, inherited_addresses)` triple, which holds for current SQLi rules. The cache is conservative: any non-trivially-clean result skips caching. False negatives (unnecessary re-evaluation) are possible; false positives (skipping a real attack) are not.