Document Version: 1.0.0
Classification: Defensive Engineering & Threat Mitigation
Governing Standards: OWASP Top 10 (2021/2025), STRIDE Threat Modeling, India DPDP Act 2023, IT Act 2000 Section 43A, PCI-DSS Level 4 Guidance

The threat model evaluates the system across six threat categories, mapping system assets against potential adversarial actors and exposure surfaces:

graph TD
    Attacker([Threat Actor]) --> Surface{Attack Surface}
    Surface -->|Malicious Input| WebApp[Browser Client App]
    Surface -->|Token Theft / Replay| PostgREST[Supabase PostgREST Engine]
    Surface -->|Document Exploits| Storage[Document Upload Vault]
    Surface -->|IDOR / State Tampering| DB[(PostgreSQL Database)]

    subgraph STRIDE["STRIDE Threat Vectors"]
        S["<b>S</b>poofing: Impersonating Admins / NGOs"]
        T["<b>T</b>ampering: Falsifying Invoice / Donation Proofs"]
        R["<b>R</b>epudiation: Denying Disbursed Funds"]
        I["<b>I</b>nformation Disclosure: Leaking Beneficiary PII"]
        D["<b>D</b>enial of Service: Flooding Distress Ticket Queues"]
        E["<b>E</b>levation of Privilege: Client-Side RBAC Tampering"]
    end

• Identity Provider: Supabase GoTrue identity server utilizing RFC 7519 JSON Web Tokens (JWT).
• Token Lifetime: Short-lived access tokens (1 hour expiration) paired with cryptographically secure rolling refresh tokens stored in secure client storage.
• Session Lifecycle: Managed via supabase.auth.onAuthStateChange with automatic token refresh before expiration (autoRefreshToken: true).

• Current Code State: RegisterPage.tsx enforces password.length < 6 (Flagged as Vulnerability SEC-FINDING-04).
• Production Policy Specification:
  • Minimum length: 12 characters.
  • Entropy requirement: At least 1 uppercase letter, 1 lowercase letter, 1 number, and 1 special symbol ([!@#$%^&*]).
  • Breached Password Check: Integration with HaveIBeenPwned API via Supabase Auth configuration to prevent credential stuffing.
  • Rate-Limiting: Lock account for 15 minutes after 5 consecutive failed login attempts.

• High-Privilege Roles: Mandatory Time-based One-Time Password (TOTP via Google Authenticator / Authy) for all accounts with ADMIN, GOVERNMENT, or NGO roles.
• Low-Bandwidth Beneficiary Access: Passwordless SMS OTP (via Fast2SMS / Twilio) providing instant 6-digit verification without password memorization burdens.

sequenceDiagram
    autonumber
    actor Attacker as Malicious Client
    participant API as PostgREST API
    participant RLS as PostgreSQL Engine (RLS)
    participant Data as public.fund_utilizations

    Attacker->>API: PATCH /fund_utilizations?id=eq.util-999<br/>Body: {"amount": 900000} (Forged Token)
    API->>RLS: Evaluates policy: "NGOs can update own utilizations"
    RLS->>RLS: Check: project_id IN (SELECT id FROM projects WHERE ngo_id = auth.uid())
    RLS-->>API: 0 Rows Affected / 403 Forbidden
    API-->>Attacker: HTTP 403 Forbidden (Insecure Direct Object Reference Blocked)

Client-side authorization checks (can(action) in AuthContext.tsx) are purely cosmetic for user interface rendering. The authoritative defense perimeter resides entirely within PostgreSQL RLS policies in supabase/migrations/20261001_realtime_auth_rls.sql:

1. Beneficiary Data Isolation:

   CREATE POLICY beneficiary_own_cases ON public.help_requests
   FOR ALL TO authenticated
   USING (beneficiary_id = auth.uid() OR current_user_role() IN ('ADMIN', 'NGO'));

2. NGO Project Management Isolation:

   CREATE POLICY ngo_manage_own_projects ON public.projects
   FOR ALL TO authenticated
   USING (ngo_id = auth.uid() OR current_user_role() = 'ADMIN')
   WITH CHECK (ngo_id = auth.uid() OR current_user_role() = 'ADMIN');

3. Financial Utilization Immutability:

   CREATE POLICY ngo_log_own_utilization ON public.fund_utilizations
   FOR INSERT TO authenticated
   WITH CHECK (
       current_user_role() = 'ADMIN' OR
       EXISTS (
           SELECT 1 FROM public.projects 
           WHERE projects.id = fund_utilizations.project_id 
           AND projects.ngo_id = auth.uid()
       )
   );

1. Notice & Consent: Citizens submitting help requests receive plain-language notices in their chosen vernacular language explaining that their name and medical distress description will be shared with accredited regional NGOs for relief delivery.
2. Data Minimization: Financial records and hospital bills are retained only for the statutory audit duration required by the Income Tax Act (7 years), after which medical records are scrubbed.
3. Right to Erasure: Beneficiaries can request complete deletion of closed case records, which scrubs names, phone numbers, and address coordinates while retaining anonymized statistical metrics.

• Zero Cardholder Data Storage: NGO Digital Connect never touches, transmits, or stores credit/debit card primary account numbers (PAN), CVVs, or UPI PINs.
• Tokenized Gateways: All financial checkout flows delegate entirely to PCI-DSS Level 1 certified gateways (Razorpay / Cashfree) via secure iframe or redirect modals.
• Section 80G Compliance: Donor PAN numbers collected for 80G tax certificates are masked (e.g. ABCDE****F) in public views and stored encrypted in the database.

The following audit findings represent active vulnerabilities identified in the codebase scan:

flowchart LR
    Detect[1. Detection & Alerting] --> Contain[2. Containment: Revoke Sessions / Block IP]
    Contain --> Eradicate[3. Eradication: Patch Vulnerability / Purge Malicious Data]
    Eradicate --> Recover[4. Recovery: Restore DB from WAL Point-in-Time]
    Recover --> Review[5. Post-Incident Review & Regulatory Disclosure]

1. P1 (Critical Data Breach / Unauthorized Admin Access):
   • Action: Immediately revoke all active Supabase GoTrue JWT refresh tokens (auth.admin.signOut()).
   • Rotate SUPABASE_SERVICE_ROLE_KEY and database passwords in the Supabase management console.
   • If citizen PII is compromised, notify the Indian Computer Emergency Response Team (CERT-In) within 6 hours as mandated by CERT-In directions.
2. Automated Point-in-Time Recovery (PITR):
   • PostgreSQL Write-Ahead Logging (WAL) enabled with 7-day continuous PITR backup.
   • Daily encrypted database dumps pushed to an isolated, multi-region AWS S3 bucket with Object Lock (WORM).

• Hardcoded Secrets Check: Verify zero private API keys, service role keys, or database credentials exist in git history.
• Production Demo Removal: Ensure loginAsRole and the 1-click demo login buttons are completely stripped from production bundles.
• RLS Audit: Run automated tests confirming that a Beneficiary JWT cannot read another Beneficiary's case documents or an unverified NGO's private drafts.
• Security Headers: Enforce modern HTTP headers via hosting configuration (Vercel / Cloudflare / Netlify):
  • Content-Security-Policy: default-src 'self'; connect-src 'self' https://*.supabase.co wss://*.supabase.co; img-src 'self' data: https:; script-src 'self'; style-src 'self' 'unsafe-inline';
  • Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY
  • Referrer-Policy: strict-origin-when-cross-origin
• MIME-Type & Anti-Malware Validation: Ensure Supabase Storage rejects all non-PDF and non-image file uploads.
• Input Sanitization: Verify all user-generated content rendered into DOM elements is properly escaped to prevent Cross-Site Scripting (XSS).

1. Should emergency distress cases allow anonymous submissions without phone number verification, or does this expose the system to coordinated spam attacks?
2. What cryptographic protocol should be adopted for tamper-proofing digital Section 80G tax receipts (e.g. SHA-256 HMAC digital seal vs. government-approved DSC token)?
3. What is the statutory retention requirement under Indian law for deleted citizen distress requests containing medical records?

1. Apply code patches to resolve the 8 vulnerabilities documented in Section 6.
2. Review the high-level design and architectural decision records in SYSTEM_ARCHITECTURE.md.
3. Configure automated security scans using GitHub CodeQL and Trivy in the CI/CD pipeline.