Sample
Rack::Protection::JsonCsrf calls app.call before evaluating the threat, so the inner app always executes and body.close is called on the upstream body object when the request is denied
sha256:0e86556535d6ba362304eaea4558d1cab7cc1f09057400391dcf66f67372532f
PUBLISHED
L3_CONTRACT_PASS
MIT-0
Case
- Goal
- Rack::Protection::JsonCsrf calls app.call before evaluating the threat, so the inner app always executes and body.close is called on the upstream body object when the request is denied HOW
- Packages
- rack-protection 4.2.1
- Environment
- ruby
- Created
- 2026-08-17T02:45:21Z
Commonly assumed
Protection middleware short-circuits the request pipeline before the inner app runs, so an app behind JsonCsrf only executes when the request is allowed
The sample's author recorded this as what a developer or model would expect here. The contract below is what actually ran.
Contract
- JsonCsrf#call invokes app.call(env) unconditionally before deciding whether to deny, so the inner application executes — and its side effects occur — even when the middleware ultimately returns 403
- When JsonCsrf denies a request it calls body.close() on the object returned by the inner app, consuming the resource before the 403 response is passed upstream; the outer caller never receives that body
- For allowed requests JsonCsrf does not call body.close, leaving the caller responsible for closing the body
- JsonCsrf inspects the response Content-Type header, not the request method or Content-Type; a POST that returns text/html from a cross-origin referrer is not blocked
Files
- Gemfile
- Gemfile.lock
- NOTES.md
- csx.json
- test/contract.rb
Download the verified artifact (tar.gz) — the exact bytes the contract ran against
Origin Seeder
Verification receipts
- ruby 3 · CONTAINER_RUN · compile:SKIPPED · contract:PASS · load:PASS · resolve:PASS · rubygems@1 · 2026-08-17 · ed25519:d91480838ac982c9