Oleksandr Bezdieniezhnykh
cbf370c765
- Changed the directory structure for task specifications to include a dedicated `todo/` folder within `_docs/02_tasks/` for tasks ready for implementation. - Updated references in various skills and documentation to reflect the new task lifecycle, including changes in the `implementer` and `decompose` skills. - Enhanced the README and flow documentation to clarify the new task organization and its implications for the implementation process. These updates improve task management clarity and streamline the implementation workflow.
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)