missions/_docs/02_document/tests/security-tests.md

# Security Tests

> **Status**: produced by autodev `/test-spec` Phase 2 (2026-05-14), revised in cycle-update mode (drift findings Phase 2) for the ECDSA+JWKS JWT model.
> **Naming**: post-rename target. Security tests focus on the JWT bearer + Authz boundary defined in AC-5 and AC-9.
> **Auth model**: ECDSA-SHA256 with JWKS retrieved from `admin` (mocked via `jwks-mock` in tests), iss + aud + alg-pin validated, 30s clock skew. The CMMC L2 row 3 (`iss`/`aud`) finding is now structurally fixed in code; the corresponding NFT-SEC scenarios now assert REJECTION, not acceptance.

---

### NFT-SEC-01: Missing Authorization header → 401

**Summary**: Verifies AC-5.4 — every protected endpoint rejects requests without an `Authorization` header.
**Traces to**: AC-5.4

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | `GET /vehicles` with no `Authorization` header | `401` |
| 2 | `GET /missions` with no `Authorization` header | `401` |
| 3 | `GET /missions/{any}/waypoints` with no `Authorization` header | `401` |
| 4 | `POST /vehicles` with no `Authorization` header + valid body | `401` (no row written — verify via side-channel `count` unchanged) |

**Pass criteria**: every protected endpoint returns 401; no DB side-effect.

---

### NFT-SEC-02: Invalid signature → 401

**Summary**: Verifies AC-5.5 — token whose ECDSA signature doesn't verify against any cached JWKS public key is rejected.
**Traces to**: AC-5.5

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Acquire valid signed token `T_good` from `jwks-mock POST /sign`, then flip a single byte in the token's signature segment to produce `T_bad` | — |
| 2 | `GET /vehicles` with `Authorization: Bearer T_bad` | `401` |
| 3 | Acquire token from a SEPARATE ECDSA keypair not present in the mock's published JWKS (via an out-of-band test helper) and call `GET /vehicles` | `401` |

**Pass criteria**: both bad-signature cases return `401`.

---

### NFT-SEC-03: Expired token outside skew → 401; inside skew → 200

**Summary**: Verifies AC-5.6 + AC-5.2 (**30s** clock skew, tighter than .NET's 5-min default and the legacy 1-min setting).
**Traces to**: AC-5.2, AC-5.6

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Request token via `POST /sign { "exp_offset_seconds": -60 }` (exp = now - 60s; outside the 30s skew) | mock returns signed JWT |
| 2 | `GET /vehicles` with `Authorization: Bearer T_exp` | `401` |
| 3 | Request token via `POST /sign { "exp_offset_seconds": -15 }` (exp = now - 15s; inside the 30s skew) | mock returns signed JWT |
| 4 | `GET /vehicles` with `Authorization: Bearer T_skew` | `200` |

**Pass criteria**: `T_exp` rejected; `T_skew` accepted.

---

### NFT-SEC-04: Token with `iss` ≠ `JWT_ISSUER` → 401

**Summary**: Verifies AC-5.11 — `ValidateIssuer = true` with `ValidIssuer = <resolved JWT_ISSUER>`. This is the structural fix for CMMC L2 row 3 row (issuer validation half).
**Traces to**: AC-5.3, AC-5.11

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Request token via `POST /sign { "iss": "https://attacker.example.com" }` (every other claim valid) | mock returns signed JWT — the signature is correct, only `iss` is wrong |
| 2 | `GET /vehicles` with that token | `401` |
| 3 | Request token via `POST /sign { }` (iss defaults to the mock's `JWT_ISSUER` env, which matches `missions`'s configured `ValidIssuer`) | mock returns signed JWT |
| 4 | `GET /vehicles` with that token | `200` |

**Pass criteria**: wrong-`iss` rejected with 401; matching-`iss` accepted.

---

### NFT-SEC-04b: Token with `aud` ≠ `JWT_AUDIENCE` → 401

**Summary**: Verifies AC-5.12 — `ValidateAudience = true` with `ValidAudience = <resolved JWT_AUDIENCE>`. This is the structural fix for CMMC L2 row 3 (audience validation half).
**Traces to**: AC-5.3, AC-5.12

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Request token via `POST /sign { "aud": "wrong-audience" }` (every other claim valid) | mock returns signed JWT |
| 2 | `GET /vehicles` with that token | `401` |

**Pass criteria**: wrong-`aud` rejected with 401.

---

### NFT-SEC-05: Missing `permissions` claim → 403

**Summary**: Verifies AC-5.8 — valid signature + lifetime is not enough; the `permissions=FL` claim is required.
**Traces to**: AC-5.8, AC-9.1

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Mint token with no `permissions` claim, valid otherwise |  |
| 2 | `GET /vehicles` | `403` |

**Pass criteria**: `403`.

---

### NFT-SEC-06: Wrong `permissions` claim value → 403; multi-permission token accepted

**Summary**: Verifies AC-9.1 + AC-9.2 — the policy is `RequireClaim("permissions", "FL")` (contains-match, not exact body-match). Wrong values → 403; a multi-permission token where one value equals `"FL"` → 200.
**Traces to**: AC-9.1, AC-9.2

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Acquire token with `permissions="ADMIN"`, valid otherwise | mock returns signed JWT |
| 2 | `GET /vehicles` | `403` |
| 3 | Acquire token with `permissions="fl"` (lowercase) | mock returns signed JWT |
| 4 | `GET /vehicles` | `403` |
| 5 | Acquire token with `permissions="FLight"` | mock returns signed JWT |
| 6 | `GET /vehicles` | `403` |
| 7 | Acquire token with `permissions: ["FL", "ADMIN"]` (multi-permission array) | mock returns signed JWT |
| 8 | `GET /vehicles` | `200` (contains-match accepts `"FL"` among the values) |

**Pass criteria**: rows 2, 4, 6 → 403; row 8 → 200.

---

### NFT-SEC-07: Health endpoint exempt from auth

**Summary**: Verifies AC-7.1, AC-9.4 (contrast) — `/health` is anonymous.
**Traces to**: AC-7.1, AC-9.4

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | `GET /health` with no `Authorization` | `200` |
| 2 | `GET /health` with `Authorization: Bearer <expired token>` | `200` (auth not evaluated) |

**Pass criteria**: `200` in both cases.

---

### NFT-SEC-08: Stack trace not leaked in 500 body

**Summary**: Verifies AC-8.6 + AC-10.3 — internal exception details stay in the log, not the HTTP body.
**Traces to**: AC-8.6, AC-10.3

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Force a `500` (drop `vehicles` table mid-test, then `GET /vehicles/{any}`) |  |
| 2 | Inspect response body | `body == { "statusCode":500, "message":"Internal server error" }` exactly; NO key matching `stack`, `stackTrace`, `exception`, `inner`, `trace`; NO file path; NO type name in the body |
| 3 | `docker logs missions \| grep "Unhandled exception"` | At least one matching line; line contains the file path of the throw site OR the exception type name (the log-side info is private to operators) |

**Pass criteria**: response body contains only `statusCode`, `message`; log contains stack info.

---

### NFT-SEC-09: SQL injection guard via parameterised queries

**Summary**: Defensive — verifies linq2db's parameterised query path is in effect for filter strings.
**Traces to**: AC-1.6 (filter), AC-2.3 (filter), defensive

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | `GET /vehicles?name='%20OR%20'1'%3D'1` (URL-encoded `' OR '1'='1`) | `200`; `body.length == 0` (no row matches the literal `' OR '1'='1` string against `BR-01` etc.) |
| 2 | `GET /missions?name=%3B%20DROP%20TABLE%20vehicles%3B%20--` (URL-encoded `; DROP TABLE vehicles; --`) | `200`; `body.TotalCount == 0`; side-channel verifies `vehicles` table still exists |

**Pass criteria**: filter inputs are treated as literal strings; no SQL execution; no DDL side-effect.

---

### NFT-SEC-10: Algorithm-pin defends against HS256-confusion → 401

**Summary**: Verifies AC-5.1 + AC-5.10 — `ValidAlgorithms = [SecurityAlgorithms.EcdsaSha256]` defends against the HS256-confusion attack where an attacker who learns a JWKS public key (which is, by definition, public) attempts to forge a token signed with that public key as the HMAC secret under `alg: HS256`.
**Traces to**: AC-5.1, AC-5.10

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Acquire the published JWKS public key bytes from `GET https://jwks-mock:8443/.well-known/jwks.json` (or use the mock's helper that returns those bytes for the test) | — |
| 2 | Acquire token via `POST /sign { "alg_override": "HS256" }` — the mock signs the JWT body with the public-key bytes as the HMAC secret (mimicking an attack) | mock returns HS256-signed JWT |
| 3 | `GET /vehicles` with `Authorization: Bearer T_hs256` | `401` |
| 4 | Acquire token via `POST /sign { "alg_override": "none" }` (mock emits unsigned JWT) | mock returns unsigned JWT |
| 5 | `GET /vehicles` with that token | `401` |

**Pass criteria**: both HS256-confusion attack and unsigned token are rejected with `401`.

---

### NFT-SEC-11: Unknown `kid` (rotation lag) → 401 until JWKS refresh

**Summary**: Verifies AC-5.7 — a token signed with a key whose `kid` is not in the cached JWKS is rejected; once the JWKS refreshes and includes the new `kid`, the same `kid` becomes accepted.
**Traces to**: AC-5.7

**Preconditions**:
- `missions` has a warm JWKS cache (any previous protected request succeeded).
- `jwks-mock` `OldKeyGraceSeconds = 5`.

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | `POST https://jwks-mock:8443/rotate-key {}` | mock returns `{ "newKid": "new-kid" }` |
| 2 | Immediately request token via `POST /sign {}` (signs with NEW kid, before `missions` JWKS cache refreshes) | mock returns signed JWT with header `kid: new-kid` |
| 3 | `GET /vehicles` with that token | `401` (cached JWKS doesn't yet contain `new-kid`) |
| 4 | Wait for `missions`'s JWKS cache to refresh (≤ 90s; the mock sets `Cache-Control: max-age=60` so the refresh tick is at most ~60s) | — |
| 5 | `GET /vehicles` with the same token (still valid lifetime) | `200` |
| 6 | Request token signed with the PREVIOUS `kid` within the `OldKeyGraceSeconds=5` window | mock signs with the old key |
| 7 | `GET /vehicles` with that token | `200` (both keys are in the JWKS during grace) |
| 8 | Wait > 5s, then request token signed with the OLD `kid` — mock should refuse (key already evicted from its sign-pool) | mock returns 400/410 |

**Pass criteria**: rotation completes transparently within the cache-refresh window; tokens minted with the new `kid` are rejected during the lag, accepted after.
**Max execution time**: 120s.

---

### NFT-SEC-12: Missing `JWT_JWKS_URL`/`JWT_ISSUER`/`JWT_AUDIENCE` → startup throws

**Summary**: Verifies AC-6.1 / AC-6.2 — `Infrastructure/ConfigurationResolver.ResolveRequiredOrThrow` fail-fast for each of the four required env vars eliminates the legacy "silent dev fallback" failure mode.
**Traces to**: AC-6.1, AC-6.2, E1, E3

**Steps** (run as four separate `docker run` invocations):

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | `docker run` `missions` with `DATABASE_URL` unset and the three JWT vars set | container exits non-zero within 5s; logs contain `InvalidOperationException` mentioning `DATABASE_URL` (or `Database:Url`) |
| 2 | `docker run` with `JWT_ISSUER` unset | container exits non-zero; logs mention `JWT_ISSUER` (or `Jwt:Issuer`) |
| 3 | `docker run` with `JWT_AUDIENCE` unset | container exits non-zero; logs mention `JWT_AUDIENCE` (or `Jwt:Audience`) |
| 4 | `docker run` with `JWT_JWKS_URL` unset | container exits non-zero; logs mention `JWT_JWKS_URL` (or `Jwt:JwksUrl`) |
| 5 | `docker run` with `JWT_JWKS_URL=http://jwks-mock:8443/...` (HTTP not HTTPS) and the other three set | container STARTS (config resolution passes); first protected request returns 500 with a log line mentioning HTTPS / `RequireHttps` |

**Pass criteria**: rows 1–4 → process exits before HTTP server binds; row 5 → process starts but the first protected request fails at JWKS fetch time.
**Max execution time**: 60s (4 docker-run cycles).

---

### NFT-SEC-13: CORS Production-gate fail-fast (E9 lock test)

**Summary**: Verifies AC-6.11 — in `ASPNETCORE_ENVIRONMENT=Production` with empty `CorsConfig:AllowedOrigins` and `CorsConfig:AllowAnyOrigin != true`, `CorsConfigurationValidator.EnsureSafeForEnvironment` throws and the process exits non-zero.
**Traces to**: AC-6.11, E9

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | `docker run` `missions` with `ASPNETCORE_ENVIRONMENT=Production` and **no** `CorsConfig` env vars | container exits non-zero within 5s; logs contain `InvalidOperationException` mentioning `CorsConfig` / `AllowedOrigins` / Production |
| 2 | Same as 1 but with `CorsConfig__AllowAnyOrigin=true` set | container starts; logs contain a warning that CORS is permissive in Production (recommend listing explicit origins) but NO throw |
| 3 | Same as 1 but with `CorsConfig__AllowedOrigins__0=https://operator.example.com` set | container starts; `OPTIONS /vehicles` preflight from `https://operator.example.com` returns `200` with the corresponding `Access-Control-Allow-Origin` echo |
| 4 | Same as 3, preflight from `https://attacker.example.com` | preflight responds without the allow-origin echo (the policy refuses the disallowed origin) |
| 5 | `docker run` with `ASPNETCORE_ENVIRONMENT=Development` (or unset → defaults to `Production`-no, actually unset defaults to `Production` per ASP.NET Core; use `Test` here) and no `CorsConfig` | container starts; logs contain `PermissiveDefaultWarning` |

**Pass criteria**: row 1 → fail-fast; rows 2–4 → start with the expected CORS posture; row 5 → start with the documented permissive fallback + warning.
**Max execution time**: 90s.

---

## Notes

- Tests that drop tables (NFT-SEC-08) run in a per-class fixture that recreates the schema before subsequent tests.
- NFT-SEC-04 / NFT-SEC-04b / NFT-SEC-10 / NFT-SEC-11 / NFT-SEC-12 / NFT-SEC-13 are NEW scenarios added in the 2026-05-14 drift re-verification cycle. They replace / extend the old "permissive iss/aud" + "shared-secret rotation" + "dev-fallback footgun" assumptions of the pre-revision spec.
- No fuzz testing today (recommended follow-up under a separate refactor cycle).