Bỏ qua

Security Requirements - Football Field Booking System

Version: 1.0 Last Updated: 2026-01-13 Owner: Security Lead / Tech Lead Applies to: API Gateway + all microservices + databases + Kafka + Redis + Keycloak + CI/CD + deployments

1) Security Objectives

  • Protect customer data (PII), booking data, payment references, and audit logs.
  • Prevent unauthorized access (authn/authz correctness).
  • Ensure integrity of bookings (no double-booking, no tampering) and payments (no duplicate charges).
  • Reduce blast radius through least privilege and segmentation.
  • Detect and respond to incidents quickly using logs/traces/alerts.

2) Threat Model (High Level)

2.1 Assets

  • User PII: email, phone, profile details, Zalo identifiers.
  • Booking data: fieldId, userId, timeslots, receipts.
  • Payment data: provider transaction IDs, payment status (no raw card storage).
  • Auth tokens: access/refresh tokens, Keycloak credentials.
  • Infrastructure secrets: DB passwords, Redis password, Kafka credentials, webhook secrets.

2.2 Trust Boundaries

  • Public internet → API Gateway
  • API Gateway → internal services network
  • Services → datastores (Postgres/Mongo/Redis)
  • Services → Kafka
  • External providers → payment webhooks endpoints

2.3 Common Attack Scenarios

  • Credential stuffing / brute force against auth endpoints.
  • Token theft and replay.
  • Broken access control (IDOR) for bookings/fields.
  • Double booking via race conditions.
  • Payment webhook forgery / replay (fake “payment success”).
  • Injection attacks (SQL/NoSQL), SSRF, path traversal, deserialization.
  • Supply chain attacks (malicious dependency, compromised CI runner).
  • Data exfiltration from logs/secrets.

3) Authentication Requirements (Keycloak / OIDC)

SEC-1: Centralized Authentication

Priority: P0

Requirements

  • Use Keycloak (OIDC) as the identity provider.
  • API Gateway must validate access tokens:
  • signature verification
  • issuer (iss) and audience (aud) checks
  • token expiration
  • nonce/state where applicable for browser flows
  • Services must accept identity context from gateway and/or re-validate tokens (defense in depth).

SEC-2: Token Policy

Priority: P0

Requirements

  • Access token TTL: 15 minutes
  • Refresh token TTL: 7 days
  • Rotate refresh tokens on use (recommended).
  • Support forced logout / token revocation for compromised accounts.

SEC-3: MFA (Phase 2)

Priority: P2

  • Require MFA for ADMIN users and sensitive operations (e.g., approving fields, refunds).

4) Authorization Requirements (RBAC + Resource-level)

SEC-4: Role-Based Access Control

Priority: P0

Roles

  • ADMIN: system administration, approvals, refunds.
  • OWNER: manage own fields, view own bookings.
  • CUSTOMER: search and create/manage own bookings.

SEC-5: Resource-Level Authorization (Anti-IDOR)

Priority: P0

Requirements

  • Booking endpoints:
  • Only booking owner (or admin) can view/cancel a booking.
  • Field endpoints:
  • Only field owner (or admin) can update field details.
  • Profile endpoints:
  • Only the user (or admin) can update profile.

Acceptance Criteria

  • Attempts to access others’ resources return 403 (or 404 where appropriate).

5) API Security Controls

SEC-6: Rate Limiting & Abuse Protection

Priority: P0

Requirements

  • Enforce rate limiting at API Gateway:
  • Auth endpoints: 5 req/min/user or IP
  • Default: 100 req/min/user
  • Payment endpoints: 10 req/min/user
  • Add IP-based throttling for unauthenticated endpoints (search).
  • Implement account lockout / captcha after repeated failures (Phase 2).

SEC-7: Input Validation & Schema Enforcement

Priority: P0

Requirements

  • Validate all incoming payloads with strict DTO validation (no unknown fields unless explicitly allowed).
  • Enforce content-type (application/json) where applicable.
  • Normalize and validate time fields for bookings (UTC).

SEC-8: CORS, CSRF, Security Headers

Priority: P0

Requirements

  • CORS allowlist only for trusted origins (web frontend domains).
  • If using cookies for auth, enable CSRF protection (double-submit or same-site cookies + CSRF token).
  • Enable security headers at gateway (e.g., X-Content-Type-Options, X-Frame-Options, Content-Security-Policy as needed).

6) Data Security

SEC-9: Encryption in Transit

Priority: P0

Requirements

  • Use TLS 1.2+ (prefer TLS 1.3) for:
  • Client → gateway
  • service → service (mTLS recommended in Kubernetes)
  • service → DB (where feasible)

SEC-10: Encryption at Rest

Priority: P1

Requirements

  • Enable disk encryption at node/storage level (K8s volumes / cloud-managed storage).
  • Protect database backups with encryption and access controls.

SEC-11: Secrets Management

Priority: P0

Requirements

  • Never store secrets in git.
  • Use Kubernetes secrets (or Vault) for:
  • DB passwords
  • Redis password
  • Kafka credentials (if enabled)
  • payment webhook secrets
  • email/ZNS provider API keys
  • Rotate secrets at least quarterly (or immediately after incident).

SEC-12: Logging & PII Redaction

Priority: P0

Requirements

  • Do not log:
  • passwords
  • tokens
  • full payment payloads containing sensitive data
  • Mask/obfuscate PII where possible (email/phone partial).
  • Store audit logs separately from app logs (logical separation at minimum).

7) Payment Security (PCI & Webhooks)

SEC-13: PCI-DSS Compliance Boundary

Priority: P0

Requirements

  • Never store raw card data.
  • Store only:
  • provider payment intent id
  • provider transaction id
  • last4/brand (optional) if provided and allowed

SEC-14: Webhook Verification & Replay Protection

Priority: P0

Requirements

  • Verify webhook signatures (Stripe/VNPay) using configured secrets.
  • Reject unsigned/invalid signature payloads with 401/400.
  • Implement idempotency:
  • deduplicate on provider event id
  • safe retries (at-least-once delivery)
  • Record webhook receipt with traceId/requestId for audit.
  • Validate event type and booking/payment mapping before updating state.

8) Infrastructure & Network Security

SEC-15: Network Segmentation

Priority: P1

Requirements

  • In Kubernetes, use NetworkPolicies:
  • Only gateway accepts inbound from internet.
  • Services can only talk to required dependencies.
  • Datastores not exposed publicly.

SEC-16: Least Privilege (DB/Kafka/Redis)

Priority: P0

Requirements

  • Separate DB users per service with minimal grants.
  • Restrict Kafka ACLs (publish/consume only needed topics).
  • Redis password required (already in docker-compose) and protected.

SEC-17: Container & Runtime Hardening

Priority: P1

Requirements

  • Run containers as non-root.
  • Read-only root filesystem where possible.
  • Pin base images and apply security updates regularly.
  • Configure resource limits (CPU/memory) to mitigate DoS.

9) Application Security (OWASP ASVS / Top 10)

SEC-18: Injection Prevention

Priority: P0

  • Use parameterized queries/ORM (TypeORM).
  • Validate and sanitize dynamic filters for search endpoints.
  • For MongoDB, avoid direct $where or untrusted query operators.

SEC-19: SSRF & External Requests

Priority: P1

  • Any outbound HTTP calls must use allowlists for hosts (payment/notification providers).
  • Disallow arbitrary URL fetching from user input.

SEC-20: File Upload Security (Avatar/Images)

Priority: P1

  • Enforce file size limit and allowed content types.
  • Virus scanning (Phase 2).
  • Store uploads in object storage (preferred) and serve via CDN.

10) Auditing & Compliance

SEC-21: Audit Logging

Priority: P1

Audit events

  • Admin actions (field approvals, user bans, refunds)
  • Payment status transitions
  • Booking cancellations

Retention

  • Minimum 1 year (or per local regulation / thesis requirements).

11) Security Testing Requirements

SEC-22: Automated Security Checks in CI

Priority: P0

  • Dependency vulnerability scanning (npm audit / SCA tool).
  • Static analysis (CodeQL already present in repo).
  • Secret scanning (pre-commit + CI).

SEC-23: DAST / Pen Testing (Phase 2)

Priority: P2

  • Run OWASP ZAP baseline scan against staging.
  • Perform manual testing for:
  • IDOR
  • auth bypass
  • webhook forgery

SEC-24: Test Plan (Minimum)

Priority: P0

  • Auth tests: invalid token, expired token, wrong audience.
  • Authorization tests: attempt to access others’ bookings/fields.
  • Rate limit tests: login brute force thresholds.
  • Webhook tests: invalid signature and replayed events.
  • Input validation tests: invalid time ranges, negative prices, oversized payloads.

12) Incident Response Plan

SEC-25: Detection & Triage

Priority: P1

  • Alerts for:
  • error rate spikes
  • auth failures spikes
  • payment webhook verification failures
  • suspicious admin actions

SEC-26: Containment

Priority: P1

  • Rotate secrets and revoke tokens.
  • Disable compromised accounts.
  • Block abusive IPs at gateway/WAF.

SEC-27: Recovery & Postmortem

Priority: P1

  • Restore from backups if integrity compromised.
  • Publish postmortem with action items and owner/ETA.

13) Security Acceptance Criteria (Release Gate)

Before production release:

  • [ ] All endpoints protected as designed (except explicitly public).
  • [ ] Role + resource authorization tests passing.
  • [ ] Webhooks signature verification implemented and tested.
  • [ ] No secrets committed; secret scanning enabled.
  • [ ] Audit logging exists for admin + payment actions.
  • [ ] Vulnerability scan has no critical/high issues (or documented mitigations).

Document Version: 1.0 Last Updated: 2026-01-13 Owner: Security Lead / Tech Lead