📌 Description
src/routes/audit.ts exposes an admin-authenticated audit log endpoint but tests/audit.test.ts currently only covers basic happy-path retrieval. There are no tests for: pagination parameters (limit, offset), redaction of any RESTRICTED fields that might appear in details JSON blobs, or rejection of invalid limit/offset values. These gaps mean the audit endpoint could leak sensitive data or be crashed by malformed pagination parameters.
💡 Why it matters: Audit logs often contain sensitive action details; without redaction tests, a code change could accidentally expose authentication tokens or Stellar addresses in audit records.
🧩 Requirements and context
- Test
GET /api/audit with ?limit=10&offset=0 — assert response array length ≤ 10
- Test
GET /api/audit with ?limit=0 — assert 400 (invalid limit)
- Test
GET /api/audit with ?limit=9999 — assert 400 or clamped to max
- Assert no
RESTRICTED field names (authToken, authorization, x-api-key) appear in any details value
- Test unauthenticated request returns
401
Non-functional requirements
- Must be secure, tested, and documented.
- Should be efficient and easy to review.
🛠️ Suggested execution
1. Fork the repo and create a branch
git checkout -b test/audit-route-pagination-redaction
2. Implement changes
- Write/modify the relevant source:
src/routes/audit.ts (if validation gaps found)
- Write comprehensive tests:
tests/routes/audit.pagination.test.ts
- Add documentation: TSDoc on the pagination query parameter constraints
- Include TSDoc on the redaction assertions in tests
- Validate security assumptions: confirm
details blobs go through PII sanitizer before storage
3. Test and commit
npm test -- --testPathPattern=audit.pagination
- Cover edge cases:
limit=0, limit=1001, offset=-1, unauthenticated request
- Include test output and security notes in the PR description.
Example commit message
test(audit): add pagination and PII-redaction tests for GET /api/audit
✅ Acceptance criteria
🔒 Security notes
The test must explicitly check that tokens, API keys, and authorization header values never appear in the details JSON of audit records. This is the most critical assertion in this issue.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
src/routes/audit.tsexposes an admin-authenticated audit log endpoint buttests/audit.test.tscurrently only covers basic happy-path retrieval. There are no tests for: pagination parameters (limit,offset), redaction of anyRESTRICTEDfields that might appear indetailsJSON blobs, or rejection of invalidlimit/offsetvalues. These gaps mean the audit endpoint could leak sensitive data or be crashed by malformed pagination parameters.🧩 Requirements and context
GET /api/auditwith?limit=10&offset=0— assert response array length ≤ 10GET /api/auditwith?limit=0— assert400(invalid limit)GET /api/auditwith?limit=9999— assert400or clamped to maxRESTRICTEDfield names (authToken,authorization,x-api-key) appear in anydetailsvalue401Non-functional requirements
🛠️ Suggested execution
1. Fork the repo and create a branch
2. Implement changes
src/routes/audit.ts(if validation gaps found)tests/routes/audit.pagination.test.tsdetailsblobs go through PII sanitizer before storage3. Test and commit
npm test -- --testPathPattern=audit.paginationlimit=0,limit=1001,offset=-1, unauthenticated requestExample commit message
✅ Acceptance criteria
limit=0returns400limit=9999returns400or is clampedlimititemsRESTRICTEDfield values appear in auditdetailsresponses401🔒 Security notes
The test must explicitly check that tokens, API keys, and authorization header values never appear in the
detailsJSON of audit records. This is the most critical assertion in this issue.📋 Guidelines