[SAR] APPENG-5143: DCR response Cache-Control header

[yuvalk]

Summary

Addresses APPENG-5143.

Adds Cache-Control: no-store and Pragma: no-cache headers to the DCR response that contains client_secret, preventing proxies and browsers from caching sensitive OAuth credentials.

Changes

• Added Cache-Control: no-store and Pragma: no-cache headers to the successful DCR response in src/lightspeed_agent/marketplace/router.py

SAR Reference

• CWE: CWE-525 (Use of Web Browser Cache Containing Sensitive Information)
• Impact: Low

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

[luis5tb]

LGTM

[luis5tb]

PR #200 Review Summary

PR: [SAR] APPENG-5143: DCR response Cache-Control header
Author: yuvalk | Size: +3 / -1, 1 file | CWE: CWE-525

Critical (1)

• Error response missing cache headers — The error path (lines 90-96) returns error and error_description without Cache-Control/Pragma headers. RFC 6749 Section 5.2 requires cache headers on token endpoint error responses too. Error descriptions could leak validation details (account states, procurement IDs) if cached by a proxy. Apply the same headers={"Cache-Control": "no-store", "Pragma": "no-cache"} to the error JSONResponse. [router.py:90-96]

Important (2)

• Add Expires: 0 for defense-in-depth — Older HTTP/1.0 proxies may not honor Cache-Control. Adding "Expires": "0" is a one-line addition recommended by RFC 7234 and OWASP OAuth best practices. [router.py:105]

• No test coverage for cache headers — No test exists for a successful DCR response at all. A test mocking register_client to return success and asserting response.headers["cache-control"] == "no-store" would verify headers survive middleware processing. [tests/test_dcr.py]

Suggestions (2)

• Unnecessary intermediate variable — The response = JSONResponse(...) / return response pattern can be simplified to a direct return JSONResponse(...). Minor style nit.

• Consider global cache policy — The security middleware sets HSTS/X-Content-Type-Options/X-Frame-Options but no cache policy. A global Cache-Control: no-store in SecurityHeadersMiddleware would prevent future endpoints from accidentally serving sensitive data without cache headers. Good follow-up task.

Strengths

• Correct fix for CWE-525 — Cache-Control: no-store is the right directive per RFC 6749 Section 5.1
• Minimal, focused diff addressing exactly one security concern
• client_secret is Fernet-encrypted at rest; no evidence of secret logging
• JWT validation and procurement API cross-referencing are sound
• Idempotent DCR handling for repeat requests is correct per RFC 7591

Verdict: Request Changes

The fix is correct on the success path but incomplete — the error response path needs the same cache headers per RFC 6749 Section 5.2. Adding Expires: 0 and a test would round it out. All three are small changes.

[luis5tb]

review fixes at PR yuvalk#6