Files
detections/_docs/02_tasks/done/AZ-147_test_security.md
T

3.0 KiB

Security Tests

Task: AZ-147_test_security Name: Security Tests Description: Implement E2E tests verifying handling of malformed payloads, oversized requests, and JWT token forwarding Complexity: 2 points Dependencies: AZ-138_test_infrastructure Component: Integration Tests Jira: AZ-147 Epic: AZ-137

Problem

The service must handle malicious or malformed input without crashing, reject oversized uploads, and correctly forward authentication tokens to downstream services. These tests verify security-relevant behaviors at the API boundary.

Outcome

  • Malformed multipart payloads return 4xx (not 500 or crash)
  • Oversized request bodies handled without OOM or crash
  • JWT token forwarded to annotations service exactly as received
  • Service remains operational after all security test scenarios

Scope

Included

  • NFT-SEC-01: Malformed multipart payload handling
  • NFT-SEC-02: Oversized request body
  • NFT-SEC-03: JWT token is forwarded without modification

Excluded

  • Authentication/authorization enforcement (service doesn't implement auth)
  • TLS verification (handled at infrastructure level)
  • CORS testing (requires browser context)

Acceptance Criteria

AC-1: Malformed multipart Given the service is running When POST /detect is sent with truncated multipart (missing boundary) or empty file part Then response is 400 or 422 (not 500) And GET /health confirms service still healthy

AC-2: Oversized request Given the service is running When POST /detect is sent with a 500MB random file Then response is an error (413, 400, or timeout) without OOM crash And GET /health confirms service still running

AC-3: JWT forwarding Given engine is initialized and mock-annotations is recording When POST /detect/{media_id} is sent with Authorization and x-refresh-token headers Then mock-annotations received the exact same Authorization header value

Non-Functional Requirements

Reliability

  • Service must not crash on any malformed input
  • Memory usage must not spike beyond bounds on oversized uploads

Integration Tests

AC Ref Initial Data/Conditions What to Test Expected Behavior NFR References
AC-1 Service running Truncated multipart + no file part 400/422, not 500 Max 5s
AC-2 Service running 500MB random file upload Error response, no crash Max 60s
AC-3 Engine warm, mock-annotations recording Detect with JWT headers Exact token match in mock Max 120s

Constraints

  • Oversized request test may require increased client timeout
  • JWT forwarding verification requires async detection to complete annotation POST
  • Malformed multipart construction requires raw HTTP request building

Risks & Mitigation

Risk 1: Oversized upload behavior varies

  • Risk: FastAPI/Starlette may handle oversized bodies differently across versions
  • Mitigation: Accept any non-crash error response (413, 400, timeout, connection reset)