feat(appsec): HTTP response monitoring SDK#3576
Conversation
BenchmarksBenchmark execution time: 2025-06-03 13:54:43 Comparing candidate commit 450a46e in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 21 metrics, 0 unstable metrics. |
| // response body (in object form, not encoded as the literal HTTP response body | ||
| // payload bytes), and returns an error if the HTTP response is configured to be |
There was a problem hiding this comment.
If we rely on the object and not the payload it will require users to modify every handler for which they want to enable this feature, as done the gin test. Is this something that we can expect from customers ?
We could do it with a middleware intercepting the response to reduce the cost of adoption.
EDIT: it seems to be the first of multiple PRs for this feature. Don't mind my comment if it won't be used as is later on.
9950270 to
9179334
Compare
This stack of pull requests is managed by Graphite. Learn more about stacking. |
There was a problem hiding this comment.
100% Optional: Move this test in internal/appsec/waf_test.go and create a ruleset in testdata to not make this test fail next time something changes the postprocessors in the default ruleset
There was a problem hiding this comment.
I feel like this test belongs here, but indeed it could use a dedicated fixed ruleset to be more future-proof.

What does this PR do?
Introduce a new
appsec.MonitorHTTPResponseBodyto submit the response body to the WAF via an SDK, so that it can be classified and its schema extracted.Motivation
This is a P0 feature for AAP, and a required building block for baking in automated collection in various integrations and via Orchestrion.
Reviewer's Checklist
golangci-lint runlocally.Unsure? Have a question? Request a review!