Gabriel Radureau 418aaeaf95 🧪 test(bdd): admin metadata endpoint security property — no secret leak ...

Activates a new @critical @admin-introspection scenario in
features/jwt/jwt_secret_retention.feature that exercises the GET
/api/v1/admin/jwt/secrets endpoint added in PR #51.

The scenario asserts the SECURITY-CRITICAL property: the metadata
endpoint exposes structure (count + per-secret is_primary, age,
fingerprint) WITHOUT leaking secret values. If a future change
accidentally adds the secret value to the response, this test fails
loud:
  SECURITY: response leaked the secret value "test-secret-do-not-leak..."

Specifically, the BDD asserts:
- After adding a secondary secret with a known value, GET returns 200
- The response contains 2 secrets in count
- The response does NOT contain the secret value anywhere
- Every entry has a non-empty SHA-256 fingerprint

4 new step definitions added to pkg/bdd/steps/jwt_retention_steps.go:
- iAddASecondaryJWTSecretNamed (parameterised by secret value)
- iRequestTheJWTSecretsMetadataEndpoint
- theMetadataShouldContainNSecrets
- theMetadataShouldNotContainTheSecretValue (the security check)
- everySecretInTheMetadataShouldHaveASHA256Fingerprint

Tests:
- Scenario passes via @admin-introspection tag filter.
- Full BDD suite (auth/config/greet/health/info/jwt) green.

The pre-existing @todo scenarios (Multiple secrets with different ages,
Cleanup frequency configuration, etc.) remain @todo — they require
arbitrary timestamp setup or manual cleanup triggers that aren't
exposed via API, by design. Documented as future test-infrastructure
work.

2026-05-05 09:55:52 +02:00

27 KiB

Raw Blame History

View Raw