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

# Security Tests

### NFT-SEC-01: Unauthenticated Access to Protected Endpoints

**Summary**: All protected endpoints reject requests without JWT token.
**Traces to**: AC-18

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | GET /users (no JWT) | HTTP 401 |
| 2 | POST /resources/{folder} upload (no JWT) | HTTP 401 |
| 3 | GET /resources/list/{folder} (no JWT) | HTTP 401 |
| 4 | PUT /users/{email}/set-role/{role} (no JWT) | HTTP 401 |
| 5 | DELETE /users/{email} (no JWT) | HTTP 401 |
| 6 | POST /classes (no JWT) | HTTP 401 |

**Pass criteria**: All remaining protected endpoints return HTTP 401 for unauthenticated requests.

> Earlier revisions of this scenario also covered `POST /resources/get`, `POST /resources/check`, and `GET /resources/get-installer`. Those endpoints were removed (AZ-197 / cycle 2) and now return 404 — see FT-N-15 (AZ-197 routes) and FT-N-16 (cycle-2 routes) in `blackbox-tests.md`.

---

### NFT-SEC-02: Non-Admin Access to Admin Endpoints

**Summary**: Non-ApiAdmin users cannot access admin-only endpoints.
**Traces to**: AC-9

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Login as Operator role user | HTTP 200, JWT token |
| 2 | POST /users (register) with Operator JWT | HTTP 403 |
| 3 | PUT /users/role with Operator JWT | HTTP 403 |
| 4 | PUT /users/enable with Operator JWT | HTTP 403 |
| 5 | DELETE /users with Operator JWT | HTTP 403 |

**Pass criteria**: All admin endpoints return HTTP 403 for non-admin users

---

### NFT-SEC-03: Password Not Returned in User List

**Summary**: User list endpoint does not expose password hashes.
**Traces to**: AC-17

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | GET /users with ApiAdmin JWT | HTTP 200, JSON array |
| 2 | Inspect each user object in response | No `passwordHash` or `password` field present |

**Pass criteria**: Password hash is never included in API responses

---

### NFT-SEC-04: Expired JWT Token Rejection

**Summary**: Expired JWT tokens are rejected.
**Traces to**: AC-4, AC-18

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Craft a JWT with `exp` set to past timestamp (same signing key) | Token string |
| 2 | GET /users with expired JWT | HTTP 401 |

**Pass criteria**: Expired token returns HTTP 401

---

### NFT-SEC-05: Encryption Key Uniqueness — OBSOLETE (cycle 2, 2026-05-14)

The `POST /resources/get/{dataFolder?}` endpoint that this test exercised was removed along with `Security.GetApiEncryptionKey` / `EncryptTo` / `DecryptTo` and `ResourcesService.GetEncryptedResource`. Per-user resource encryption is no longer part of the system. ID retained for traceability stability; do not regenerate the spec body until a full `/test-spec` rerun.

---

### NFT-SEC-06: Disabled User Cannot Login

**Summary**: A disabled user account cannot authenticate.
**Traces to**: AC-9

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Register user, disable via PUT /users/enable | HTTP 200 |
| 2 | Attempt POST /login with disabled user credentials | HTTP 409 or HTTP 403 |

**Pass criteria**: Disabled user cannot obtain a JWT token

---

## Cycle 2 Additions (2026-05-14) — Auth Modernization (AZ-529 + AZ-530)

The scenarios below were appended during the existing-code cycle 2 Test-Spec Sync (autodev Step 12) for the security-only / cryptography-invariant ACs in cycle 2. Functional flows live in `blackbox-tests.md` under the matching task. Numbering continues from NFT-SEC-06.

### NFT-SEC-07: New User Hashes Use Argon2id (AZ-536)

**Summary**: A freshly-registered user's `password_hash` is in Argon2id PHC format with parameters at or above the configured floor.
**Traces to**: AZ-536 AC-1

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | POST /users (ApiAdmin JWT) registering `freshuser@azaion.com` with a known password | HTTP 200 |
| 2 | Read `users.password_hash` for `freshuser@azaion.com` directly from Postgres | Value starts with `$argon2id$v=19$m=` |
| 3 | Parse the PHC string parameters | `m ≥ 65536`, `t ≥ 3`, `p ≥ 1` |

**Pass criteria**: All new users land in Argon2id PHC format with at least the configured cost parameters; no SHA-384 base64 strings written for new accounts.

---

### NFT-SEC-08: Argon2id Verify Has No Remotely Observable Timing Leak (AZ-536)

**Summary**: `VerifyPassword` is constant-time across wrong passwords of various lengths; timing variance does not leak information about the candidate password.
**Traces to**: AZ-536 AC-5

**Preconditions**:
- User with Argon2id-hashed password
- Test environment with low concurrency (this test is sensitive to host noise — if it intermittently trips, widen the bound or warm Argon2 with a non-test login first; see cycle-2 carry-forward F6)

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | POST /login with a wrong 8-char password, sample N=20 timings | Each → HTTP 409 WrongPassword |
| 2 | POST /login with a wrong 64-char password, sample N=20 timings | Each → HTTP 409 WrongPassword |
| 3 | Compute median of each sample; compare | `|median_8 − median_64| / median_8 < 0.20` (within 20% of each other — Argon2id cost dominates string-comparison cost) |

**Pass criteria**: Wrong-password verify time is dominated by Argon2id cost, not by string-length-dependent comparison; no exploitable timing channel.

---

### NFT-SEC-09: Per-IP Rate Limit Returns 429 (AZ-537)

**Summary**: 11 `/login` requests from the same client IP within 60 s force the 11th into HTTP 429 with a `Retry-After` header.
**Traces to**: AZ-537 AC-1

**Preconditions**:
- Rate-limit `Auth:RateLimit:PerIp` set to 10 / 60 s sliding (the test env value)
- Test client preserves source IP across requests (E2E container-shared-IP caveat applies — see test_run_report cycle 2 skip note for the legitimate environment-mismatch skip)

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | POST /login × 10 from the same IP within 5 s (any mix of right/wrong passwords) | HTTP 200 / HTTP 409 (within budget) |
| 2 | POST /login as the 11th request inside the 60 s window | HTTP 429; response includes `Retry-After` header (integer seconds) |

**Pass criteria**: 11th request inside the window is rejected with 429 + Retry-After. (Legitimate environment-mismatch skip in shared-IP container envs — verified by ASP.NET Core RateLimiter unit tests + manual probe documented in AZ-537 spec.)

---

### NFT-SEC-10: Per-Account Rate Limit Returns 429 (AZ-537)

**Summary**: 6 `/login` requests for the same email from 6 different IPs within 5 min force the 6th into HTTP 429.
**Traces to**: AZ-537 AC-2

**Preconditions**:
- Rate-limit `Auth:RateLimit:PerAccount` set to 5 / 5 min sliding
- Test ability to spoof / vary the source IP per request (e.g. via `X-Forwarded-For` if the app trusts a known forwarder, or a multi-host test fixture)

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | POST /login for `alice@azaion.com` from IPs 1..5 within 1 min (any mix of right/wrong passwords) | HTTP 200 / HTTP 409 (within budget) |
| 2 | POST /login for `alice@azaion.com` from IP 6 inside the 5 min window | HTTP 429; `Retry-After` present |

**Pass criteria**: Per-account partition triggers independently of per-IP partition.

---

### NFT-SEC-11: Account Lockout Returns 423 Even For Correct Password (AZ-537)

**Summary**: Once `failed_login_count` hits the lockout threshold, the account returns HTTP 423 Locked even for subsequent correct-password attempts until `lockout_until` passes.
**Traces to**: AZ-537 AC-3

**Preconditions**:
- `Auth:Lockout:MaxAttempts = 10` (default)
- User `bob@azaion.com` with Argon2id-hashed password

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | POST /login for `bob@azaion.com` with wrong password × 10 (across IPs / within rate budget) | First 9 → HTTP 409 WrongPassword; 10th → HTTP 423 Locked OR final 409 followed by lockout flag |
| 2 | Read `users.lockout_until` and `users.failed_login_count` for `bob` | `lockout_until > now()`; counter at threshold |
| 3 | POST /login for `bob` with correct password immediately after | HTTP 423 Locked (lockout precedes credential check) |

**Pass criteria**: Lockout state takes precedence over correct credentials within the lockout window; counter persists across IPs (per-account, not per-IP).

---

### NFT-SEC-12: Lockout Is Audit-Logged (AZ-537)

**Summary**: When NFT-SEC-11 fires the lockout transition, an audit-log row is written with the email, source IP, and timestamp.
**Traces to**: AZ-537 AC-6

**Preconditions**:
- Audit log infrastructure online (verified by existing logging tests)

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Trigger NFT-SEC-11 against `bob@azaion.com` from IP `203.0.113.7` | Lockout fires |
| 2 | Query the audit log for entries with `event = 'login_lockout'` since the test start | At least one row with `email = 'bob@azaion.com'`, `ip = '203.0.113.7'`, `timestamp` within ± 5 s of the lockout trigger |

**Pass criteria**: Each lockout produces a `login_lockout` audit entry with the security-relevant fields.

---

### NFT-SEC-13: HTTP CORS Origin Is Rejected (AZ-538)

**Summary**: A browser preflight from the cleartext `http://admin.azaion.com` origin must NOT receive an `Access-Control-Allow-Origin` header (CORS denies the request).
**Traces to**: AZ-538 AC-1

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | OPTIONS /login with `Origin: http://admin.azaion.com`, `Access-Control-Request-Method: POST` | HTTP 204 OR 200; response has NO `Access-Control-Allow-Origin` header |

**Pass criteria**: HTTP origin gets no ACAO header — browser-side fetch with credentials will fail in any compliant browser.

---

### NFT-SEC-14: HSTS Header Present in Production (AZ-538)

**Summary**: When `ASPNETCORE_ENVIRONMENT=Production`, every HTTPS response includes a strict `Strict-Transport-Security` header.
**Traces to**: AZ-538 AC-3

**Preconditions**:
- Admin container running with `ASPNETCORE_ENVIRONMENT=Production`
- Note: the default test harness runs `Development`; this test must be run with the production env override OR is the legitimate environment-mismatch skip documented in cycle-2 test_run_report

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | GET https://admin.azaion.com/health/live (or any HTTPS endpoint) | HTTP 200; response header `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload` |

**Pass criteria**: Production responses always carry HSTS with the documented directives.

---

### NFT-SEC-15: HTTP Request Redirects to HTTPS in Production (AZ-538)

**Summary**: When `ASPNETCORE_ENVIRONMENT=Production`, a cleartext HTTP request returns HTTP 307 to the same path on HTTPS.
**Traces to**: AZ-538 AC-4

**Preconditions**: Same as NFT-SEC-14

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | GET http://admin.azaion.com/health/live | HTTP 307; `Location: https://admin.azaion.com/health/live` |

**Pass criteria**: HTTP traffic is redirected at the protocol layer, not silently served.

---

### NFT-SEC-16: Refresh-Token Reuse Kills the Session Family (AZ-531)

**Summary**: If a previously-rotated refresh token is presented again, the entire `sessions` family chain (parent + all descendants) is marked `revoked_reason='reuse_detected'` and every refresh in that family stops working.
**Traces to**: AZ-531 AC-3

**Preconditions**:
- A session family with refresh R1 rotated to R2 (per FT-P-31)

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | POST /token/refresh with R1 (already rotated) | HTTP 401 |
| 2 | Query `sessions` for the family | Every row in the family has `revoked_at` set; `revoked_reason = 'reuse_detected'` |
| 3 | POST /token/refresh with R2 | HTTP 401 (R2 also dead — family-wide kill) |

**Pass criteria**: Reuse detection kills the entire family, not just the reused refresh.

---

### NFT-SEC-17: Refresh Tokens Are Opaque, Not JWT (AZ-531)

**Summary**: Refresh tokens issued by /login or /token/refresh are not JWTs; the persisted form is the SHA-256 hash; the raw value never appears in logs.
**Traces to**: AZ-531 AC-5

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | POST /login → capture `refresh_token` R | R is a non-empty string ≥ 43 chars (base64url of 32 bytes) |
| 2 | Attempt to parse R as a JWT (split on `.` and base64url-decode the segments) | Parse fails — R does not split into a JWT header/payload/signature shape |
| 3 | Read the matching `sessions.refresh_hash` column directly from Postgres | Length 32 bytes (SHA-256 raw or base64-encoded), value ≠ R |
| 4 | Grep API logs (Serilog output) for the literal R | No match (raw refresh value never logged) |

**Pass criteria**: Refresh tokens are opaque, hashed at rest, and never logged in raw form.

---

### NFT-SEC-18: Admin Tokens Are Signed With ES256 + kid (AZ-532)

**Summary**: An access token returned by /login has `alg=ES256` and a `kid` matching one of the active JWKS keys.
**Traces to**: AZ-532 AC-1

**Preconditions**:
- Admin running with at least one ES256 keypair loaded from `secrets/jwt_signing_key.pem`

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | POST /login with valid credentials | HTTP 200, dual tokens |
| 2 | Decode the access token's JOSE header | `alg == "ES256"`, `kid` non-empty |
| 3 | GET /.well-known/jwks.json | The same `kid` appears in the returned `keys` array |

**Pass criteria**: Tokens are signed asymmetrically and carry the `kid` discriminator needed for rotation.

---

### NFT-SEC-19: JWKS Endpoint Never Exposes Private Material (AZ-532)

**Summary**: The JWKS payload contains only public components; no `d`, `p`, `q`, `dp`, `dq`, or `qi` field appears.
**Traces to**: AZ-532 AC-4

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | GET /.well-known/jwks.json | HTTP 200, JSON body |
| 2 | Inspect every entry in `keys` for forbidden private-material fields | None of `d`, `p`, `q`, `dp`, `dq`, `qi` is present |

**Pass criteria**: Public-key set strictly excludes any private scalar (EC) or RSA private primes.

---

### NFT-SEC-20: alg-Confusion Attack Is Rejected (AZ-532)

**Summary**: A forged token with `alg=HS256` (where the signature is computed using the public key as the HMAC secret) is rejected by every protected endpoint, because `TokenValidationParameters.ValidAlgorithms` pins ES256 only.
**Traces to**: AZ-532 AC-5

**Preconditions**:
- Test fixture able to construct a forged JWT given the public key

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Build a JWT with header `{ "alg":"HS256","typ":"JWT","kid":"<active-kid>" }`; payload claims valid; signature = HMAC-SHA256(publicKeyBytes, signingInput) | Forged token string |
| 2 | GET /users with the forged token | HTTP 401 |

**Pass criteria**: Algorithm-confusion forgery is rejected; verifier does not silently downgrade to HS256.

---

### NFT-SEC-21: Mission Token Requires MFA Step-Up (AZ-533 + AZ-534)

**Summary**: After AZ-534 ships, `POST /sessions/mission` MUST reject access tokens whose `amr` does not include `mfa`. Caller gets 403 with a step-up message.
**Traces to**: AZ-533 AC-6

**Preconditions**:
- AZ-534 already landed (it has — cycle 2 batch 4)
- Caller holds an access token with `amr=["pwd"]` (e.g. legacy session, or a service account that doesn't enroll MFA)

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | POST /sessions/mission with the `amr=["pwd"]` access token + a valid mission body | HTTP 403; response body contains `"mission tokens require step-up MFA"` |

**Pass criteria**: Mission-class tokens cannot be minted without MFA in the access-token `amr` chain.

> Note: cycle-2 follow-up F1 in `_docs/03_implementation/implementation_report_auth_modernization_cycle2.md` calls out that `/sessions/mission` enforcement of `amr=mfa` is the small wire-up still pending after AZ-534 shipped (the AC was deferred during AZ-533, then re-opened under F1). Until F1 lands, this scenario is the spec contract; the matching test may be marked Pending in the SUT.

---

### NFT-SEC-22: TOTP Secret Is Encrypted at Rest (AZ-534)

**Summary**: The `users.mfa_secret` column never holds plaintext base32; only ciphertext.
**Traces to**: AZ-534 AC-6

**Preconditions**:
- An enrolled user from FT-P-39

**Steps**:

| Step | Consumer Action | Expected Response |
|------|----------------|------------------|
| 1 | Read `users.mfa_secret` for the enrolled user directly from Postgres | Value is non-empty |
| 2 | Try to base32-decode the value as if it were a 32-char TOTP secret | Decode either fails OR yields material that does NOT round-trip to a working TOTP code |
| 3 | Confirm the value is the output of `IDataProtector.Protect(<plaintext base32>)` (length ≫ 32 chars; format-prefixed) | Matches `IDataProtector` ciphertext shape |

**Pass criteria**: `mfa_secret` is stored encrypted; reading the DB row alone does not yield a usable TOTP secret. (Operational note: production must set `DataProtection:KeysFolder` for the `IDataProtector` to outlive container restarts — see cycle-2 carry-forward F3.)