TS_Proto/SECURITY.md

Security rules

Required security controls for TravelHub. These are not suggestions — a change that breaks one is rejected. They exist because this is a multi-tenant system holding traveller PII (names, passport numbers, contact details) where a single leaked WHERE clause exposes every tenant.

Findings from the whitebox assessment and their status are in security/VAPT-REPORT.md.

1. Tenant isolation

• The tenant id is derived from the authenticated identity, never from the URL, query string, header value, or request body. A client cannot choose or forge the tenant it acts as.
• Every query against a tenant-owned table (users, flights, bookings, passengers) filters on tenant_id as its first parameter. No exceptions.
• A miss within the tenant returns 404, never 403 — existence of another tenant's record must not be observable.
• No PostgreSQL row-level security. Isolation is enforced in the repository layer by the rules above (see CLAUDE.md for the rationale). At scale, prefer schema- or database-per-tenant, not RLS.

2. Secrets

• Never commit a secret. .env and *.env are git-ignored; only .env.example (placeholders) is tracked. Credentials, tokens and DB passwords live in .env and are read at runtime.
• The pre-commit hook scans staged content for credential patterns and blocks them. Do not bypass it (--no-verify) to commit a secret.
• Never print or log a credential. The e2e API-capture redacts the Authorization header (it is the Basic-auth secret); keep it redacted in any report or log.
• If a secret is ever committed or exposed, rotate it immediately — assume it is compromised. Scrubbing history is not enough on its own.

3. Authentication & credential storage

• Passwords are hashed with bcrypt in application code at cost ≥ 12.
• The real hash and the not-found timing-dummy hash must use the same cost — a mismatch creates a username-enumeration timing oracle (VAPT FINDING-2).
• 401 responses omit WWW-Authenticate (so the browser dialog doesn't fight the SPA sign-in); a missing user still pays for a bcrypt comparison (timing).
• Authentication endpoints must be rate-limited before any public exposure.

4. Input handling

• All SQL is parameterised ($1…$n). Never concatenate a value into SQL. Anything that must reach the SQL text (e.g. a sort column) is whitelisted.
• JSON request bodies use DisallowUnknownFields (blocks mass-assignment) and are size-capped (http.MaxBytesReader).
• Validate and normalise free-text on input; treat the API as the trust boundary, not the client.

5. Transport & least privilege

• Any non-local database connection uses TLS (sslmode=verify-full); disable is only for loopback dev.
• The running service connects to PostgreSQL as a least-privilege role (DML only), never a superuser. Migrations run under a separate, higher privileged role the service never uses.

6. Dependencies & headers

• Run dependency scanning in CI: govulncheck (Go) and npm audit (frontend).
• Responses carry baseline security headers (nosniff, X-Frame-Options, Referrer-Policy, Cache-Control: no-store on authenticated JSON, HSTS behind TLS); the SPA ships a restrictive CSP.

7. Data handling

• Treat passenger PII as sensitive. Do not log it; do not put real PII in seed or test data (use synthetic values).
• Reports (evidence, test) may contain synthetic test data only.

Reporting a vulnerability

Raise security issues privately with the repository owner (do not open a public issue). Include steps to reproduce and the affected files.