API authorization regression test in GitHub Actions
A useful authorization regression test fails when the owner check is removed and passes when both owners retain access without seeing each other’s data. Run it against a deliberately broken fixture to prove that your assertions detect the defect.
What to prepare
Place authorization-contract.py and access-fixture.py together in ci/ and the workflow in .github/workflows/. The exercise uses Python’s standard library and a temporary loopback port. It needs no hosted API or secrets.
Verification procedure
Compare the fixed and vulnerable cases locally
Fixed mode verifies two owner controls and both cross-owner reads. In vulnerable mode the first foreign marker produces exit code 1. A fixture startup problem or an unexpected response produces code 2 instead.
Replace the fixture with your application
Start your real test app inside the job, create two identities through its authentication flow and replace the request adapter. Match the agreed denial contract; that might be a deliberate 404 rather than a 403. Keep the body checks and both positive controls.
Run from the repository root after saving both scripts in ci/
python3 ci/authorization-contract.py --mode fixed
python3 ci/authorization-contract.py --mode vulnerableDecision and limitations
The supplied workflow expects exactly exit code 1 for the broken case. An absent fixture or a crashed server must not be mistaken for a successfully detected authorization bug.
What remains unverified
A green exercise job covers the fixture only. After adapting it, give writes, downloads and exports their own assertions.