# Security Design Review ## System: Identity Verification Web App (Profile Photo + Government ID Upload) --- ## PHASE 1 — System Context & Control Coverage Scope | System Dimension | Classification | Evidence | |---|---|---| | System type | Web app (identity verification / KYC-style document intake) | STATED | | User role diversity | External + internal mixed (public users uploading; internal staff reviewing) | STATED | | Data classification | Regulated (PII — government ID images, full legal names) | STATED | | Compliance framework | None named. General PII/data-protection obligations (GDPR-style principles) very likely apply given government ID collection; SOC2 relevant if this is a B2B-facing verification service | INFERRED | | Trust boundary count | Moderate — 4 explicit crossings (internet → gateway → app server → S3 → staff dashboard) | STATED | ### Gap Risk Map | Common Design Gap | Priority | Evidence Type | Conf | |---|---|---|---| | Authentication not enforced consistently at all entry points | HIGH | INFERRED | 75 | | Authorization decisions made at presentation layer only | HIGH | INFERRED | 70 | | Trust boundaries not explicitly defined — all roles treated equally | MED | INFERRED | 65 | | Sensitive data unprotected in transit or at rest | MED | INFERRED | 60 | | Third-party / supply chain dependencies without vetting | MED | INFERRED | 50 | | Logging insufficient to support incident detection | HIGH | INFERRED | 80 | **Review rationale:** This system combines the two highest-stakes properties in application security — government-issued identity documents (irreplaceable, high-value PII) and a human review workforce with broad read access to that data. That combination pushes authentication/authorization and detection-logging gaps to HIGH priority by default, because the primary realistic threat isn't just an external attacker but also insider misuse or a compromised staff credential. Encryption and supply-chain gaps are rated MED rather than HIGH only because partial mitigations (HTTPS, private bucket) are already stated to exist. --- ## PHASE 2 — System Component & Trust Boundary Map ### Components | Component | Role in System | Trust Level Assigned | Data It Handles | Connected To | Evidence Type | |---|---|---|---|---|---| | End-user client (browser/mobile) | UI layer | Untrusted | Profile photo, government ID image, full name | API Gateway | STATED | | API Gateway | Process | Partially trusted | Upload requests, metadata | Client, App Server | STATED | | App Server | Process | Partially trusted | File contents, PII metadata, validation logic | API Gateway, S3, Review Dashboard backend | STATED | | S3 Storage | Data store | Partially trusted (private bucket) | ID images, profile photos | App Server, Review Dashboard | STATED | | Internal Review Dashboard | UI layer | Fully trusted (staff) | Displays ID images + names to reviewers | S3, App Server/backend, (implied) staff identity provider | STATED | | Staff authentication mechanism | Process | Not described | Staff credentials/session | Review Dashboard | INFERRED (must exist, method unknown) | ### Trust Boundary Crossings | Data Flow | Origin | Destination | Trust Level Change | Control Required Here | Evidence Type | |---|---|---|---|---|---| | User upload | Public internet | API Gateway | Untrusted → Partially trusted | TLS (stated) + auth + input validation + rate limiting | STATED/INFERRED | | Gateway → App Server | API Gateway | App Server | Partially trusted → Partially trusted | Service-to-service auth, request validation | INFERRED | | App Server → S3 | App Server | S3 | Partially trusted → Data store | Encryption at rest, scoped IAM, private bucket (stated) | STATED/INFERRED | | S3 → Review Dashboard | S3 | Fully trusted (staff) | Data store → Fully trusted | Staff auth + role-based authorization + access audit logging | INFERRED | | Staff decision actions | Review Dashboard | Verification record | Fully trusted → data mutation | Audit trail of approve/reject actions | INFERRED | ### Assumption Ledger | Assumption | Where It Enters the Review | If False — Effect on Control Recommendations | |---|---|---| | "HTTPS everywhere" covers internal service-to-service calls, not just the public edge | Trust boundary crossings #2–#3 | Internal traffic between App Server, S3, and dashboard may be unencrypted — internal TLS/mTLS becomes required | | "S3 bucket is private" means both public-access block AND encryption at rest, not just ACL restriction | Data-at-rest assessment (Gap register #8) | Private ACL alone doesn't protect confidentiality at rest — explicit SSE requirement needed | | Internal dashboard staff authenticate via *some* login mechanism (unspecified) | Trust boundary crossing #4, Gap #1 | If the dashboard has weak/no auth, multiple gaps escalate from HIGH to CRITICAL | | "Basic file type validation" checks content/magic bytes, not just file extension | Gap register #3 (Tampering) | If extension-only, validation is trivially bypassable, raising exploit likelihood | | Dashboard access is already scoped to staff with a legitimate review need | Authorization gap severity (Gap #11) | If access is broad/unscoped, insider-risk exposure is significantly larger than assessed | ### ⚠ Coverage Blind Spots 1. **"HTTPS everywhere"** addresses transport encryption but says nothing about at-rest protection of ID images in S3, or field-level protection of full names if they live in a separate database — an unaddressed adjacent gap. 2. **"Basic file type validation"** blocks obviously wrong file types but doesn't address image-based exploits (malformed EXIF, decompression bombs, polyglot files) — and combined with the stated absence of virus scanning, this leaves the upload pipeline fully open to malicious payloads disguised as images. 3. **"S3 bucket is private"** stops external/public access but says nothing about internal IAM granularity (which services/staff can read every object) or whether the review dashboard uses long-lived vs. short-lived presigned URLs to serve images. --- ## PHASE 3 — Security Control Gap Register (STRIDE-Mapped) | # | Security Control Gap | STRIDE | Component/Flow | Likelihood | Impact | Risk | Control Present | Recommended Control | Evidence | Conf | |---|---|---|---|---|---|---|---|---|---|---| | 1 | No stated MFA/strong authentication for staff accessing the review dashboard | Spoofing | Review Dashboard | M | H | **HIGH** | NONE stated | SSO + mandatory MFA, short session lifetimes | INFERRED | 75 | | 2 | No stated rate limiting or bot protection on the public upload endpoint | Spoofing | API Gateway | H | M | **HIGH** | NONE stated | WAF + rate limiting + CAPTCHA on upload/signup | INFERRED | 65 | | 3 | File type validation described as "basic" — likely extension/MIME-only, bypassable | Tampering | App Server upload handler | H | H | **HIGH** | Basic file type validation | Magic-byte/content validation + server-side re-encode | STATED gap | 80 | | 4 | No malware/virus scanning of uploaded documents before storage or staff viewing | Tampering | App Server / S3 ingestion | H | H | **HIGH** | NONE (explicitly stated) | Malware scanning pre-storage, quarantine bucket | STATED | 95 | | 5 | No stated audit logging of staff view/approve/reject actions on PII records | Repudiation | Review Dashboard | M | H | **HIGH** | NONE stated | Immutable, structured audit log per action | INFERRED | 80 | | 6 | No stated logging of end-user upload events tied to identity | Repudiation | App Server | M | M | MED | NONE stated | Structured event logging with correlation IDs | INFERRED | 70 | | 7 | Possible predictable/long-lived access to stored ID images if dashboard doesn't use short-lived signed URLs | Info Disclosure | S3 / Review Dashboard | M | H | **HIGH** | Private bucket (partial) | Short-TTL presigned URLs, explicit deny-public bucket policy | INFERRED | 70 | | 8 | No stated encryption at rest (SSE/KMS) for S3 objects or database PII fields | Info Disclosure | S3 Storage | L | H | MED | NONE stated | SSE-KMS with customer-managed keys | INFERRED | 65 | | 9 | No stated data retention/deletion policy for ID images post-verification | Info Disclosure | S3 / App Server | M | H | MED | NONE stated | Defined retention schedule + automated deletion | INFERRED | 70 | | 10 | No stated file size limits or upload throttling | DoS | API Gateway / App Server | M | M | MED | NONE stated | Max file size, per-user quotas, async processing queue | INFERRED | 60 | | 11 | No stated RBAC distinguishing staff roles (viewer vs. decision-maker vs. admin) | Elevation of Privilege | Review Dashboard | M | H | **HIGH** | NONE stated | Server-enforced RBAC with least-privilege roles | INFERRED | 75 | | 12 | No stated server-side ownership check preventing cross-user access to another user's documents (IDOR) | Elevation of Privilege | App Server API | H | H | **HIGH** | NONE stated | Server-side ownership/role verification on every request | INFERRED | 75 | --- ## PHASE 4 — High-Priority Gap Remediation Plans ### GAP 1: No MFA/strong authentication for staff dashboard access **Why this gap matters:** Staff hold broad read access to government ID images and full names; one compromised password exposes the entire verification pipeline's PII to whoever holds that credential. **Detection capability needed:** Login alerts for staff accounts (new device, impossible travel), failed-MFA logging, session anomaly monitoring. **Recommended control:** SSO integration (e.g., Okta/Azure AD) with mandatory MFA and short session lifetimes for the dashboard specifically. **Implementation guidance:** - Inventory all accounts with dashboard access and confirm current auth mechanism - Integrate an SSO provider and enforce MFA at the identity-provider level - Cap idle session timeout (≈30 min); require step-up re-auth for approve/reject actions - Retire any local password-only accounts for the dashboard - Validate via penetration test that MFA cannot be skipped or bypassed **Residual exposure after control:** MED — phishing / MFA-fatigue attacks remain possible; phishing-resistant hardware keys reduce this further. ### GAP 2: No rate limiting/bot protection on the public upload endpoint **Why this gap matters:** Automated abuse enables mass fraudulent submissions and gives attackers a low-cost way to probe other weaknesses (e.g., the IDOR gap below). **Detection capability needed:** Alerts on abnormal request volume per IP/account, WAF block-rate dashboards, spikes in failed validation attempts. **Recommended control:** Gateway-level rate limiting plus CAPTCHA/behavioral bot detection on account creation and upload flows. **Implementation guidance:** - Enable per-IP and per-account rate limiting at the gateway - Add CAPTCHA or invisible bot detection to signup/upload - Alert on threshold breaches - Load-test to confirm limits don't degrade legitimate usage **Residual exposure after control:** MED — distributed abuse can still evade IP-based limits; pair with account-level anomaly detection. ### GAP 3: File type validation is "basic" (likely bypassable) **Why this gap matters:** A disguised malicious file (e.g., executable renamed as .jpg) could reach storage and later be opened by staff or processed by backend services. **Detection capability needed:** Log validation failures and mismatches between declared vs. detected file type; alert on repeated mismatches from one account. **Recommended control:** Content-based (magic-byte) validation combined with server-side image re-encoding to strip active content. **Implementation guidance:** - Replace extension/MIME-only checks with content-sniffing libraries - Re-encode all accepted images server-side (strip EXIF/metadata, normalize format) - Reject anything failing strict image-format parsing - Test against known-bad files (polyglots, disguised executables) **Residual exposure after control:** LOW–MED — zero-day parser exploits remain possible; combine with sandboxed processing. ### GAP 4: No malware/virus scanning of uploads **Why this gap matters:** Documents are viewed by human staff and stored long-term; embedded malware could compromise a reviewer's workstation or serve as an internal foothold. **Detection capability needed:** Scan-engine alerts on detected malware; quarantine-bucket monitoring. **Recommended control:** Malware scanning (e.g., ClamAV, cloud-native scanning, or a commercial API) inserted into the pipeline before files reach the reviewable store. **Implementation guidance:** - Route all uploads through a scan step before they land in the primary bucket - Quarantine flagged files separately and alert security - Queue/hold user notification pending scan result - Keep scanning signatures/engine current **Residual exposure after control:** LOW — targeted zero-days may still evade detection; pair with re-encoding from Gap 3. ### GAP 5: No audit logging of staff actions on PII **Why this gap matters:** Without a trail, unauthorized or excessive staff access to ID documents can't be detected, investigated, or evidenced for compliance. **Detection capability needed:** This control *is* the detection layer — logs should feed a SIEM with alerts on bulk access, off-hours access, or access with no corresponding case assignment. **Recommended control:** Immutable, centralized audit logging for every view/approve/reject/export action on identity records. **Implementation guidance:** - Instrument the dashboard backend to emit structured audit events (who, what, when, record ID, action) - Ship logs to an append-only store or SIEM - Define alert rules (e.g., one staff member viewing an unusual volume of records) - Retain logs per legal/compliance requirements **Residual exposure after control:** LOW — enables detection/response but doesn't prevent misuse by itself; pair with RBAC (Gap 11). ### GAP 7: Possible predictable/long-lived access to stored ID images **Why this gap matters:** If the dashboard references S3 objects via static or long-lived links, a leaked or guessed URL exposes a government ID image with no further authentication needed. **Detection capability needed:** Monitor S3 access logs for requests lacking the expected presigned-token pattern; alert on access from unexpected IP ranges. **Recommended control:** Exclusively short-lived (e.g., 5-minute) presigned URLs generated per authenticated staff session, plus an explicit bucket policy denying all public/anonymous access. **Implementation guidance:** - Audit how the dashboard currently generates image URLs - Replace any static/long-lived links with per-session presigned URLs - Set TTL as short as the workflow allows - Add an explicit bucket policy denying public-read regardless of object ACL **Residual exposure after control:** LOW — a leaked presigned URL is time-boxed; pair with audit logging (Gap 5) to catch misuse within the window. ### GAP 11: No RBAC distinguishing staff roles **Why this gap matters:** Without differentiated permissions, any dashboard account can potentially view or decide on identity documents beyond its actual job function, widening the insider-risk blast radius. **Detection capability needed:** Cross-reference audit logs (Gap 5) against role assignments to spot out-of-scope actions. **Recommended control:** Role-based access control with distinct roles (read-only reviewer, decision-maker, admin), enforced server-side on every request. **Implementation guidance:** - Define a role matrix mapping job functions to permitted actions - Enforce checks server-side, not just by hiding UI elements - Migrate existing staff accounts into the new roles - Periodically recertify access assignments **Residual exposure after control:** LOW–MED — role misassignment or overly broad default roles remain a risk; pair with periodic access reviews. ### GAP 12: No server-side ownership check (IDOR risk) **Why this gap matters:** If a user can access another user's uploaded ID document by manipulating an identifier, that's a direct, severe breach of real government identity documents. **Detection capability needed:** Alert when the requesting user ID doesn't match the record-owner ID at the application layer. **Recommended control:** Server-side authorization check on every document read/write, verifying the requester owns (or holds an authorized staff role for) the target record. **Implementation guidance:** - Audit every API endpoint that accepts a document/record ID - Add ownership/role-verification middleware applied consistently across endpoints - Use non-guessable identifiers (UUIDs) as defense-in-depth alongside authorization checks - Add automated tests attempting cross-account access to confirm blocking **Residual exposure after control:** LOW — once consistently enforced, this flow's IDOR risk is largely closed; ensure new endpoints inherit the same middleware. --- ## PHASE 5 — Compliance Control Checklist *No compliance framework was explicitly named. The checklist below is INFERRED from the data classification (government ID + full name = regulated PII) using common data-protection principles (GDPR-style, broadly applicable across most PII regimes).* | Compliance Control | Standard Requirement | Current State | Gap Description | Priority | Evidence | |---|---|---|---|---|---| | Lawful basis / documented purpose for collecting government ID | Data protection principle (e.g., GDPR Art. 5/6) | Unknown | No stated consent flow or documented lawful basis | 🔴 Required | INFERRED | | Data minimization | Collect only necessary ID fields | Unknown | No stated limits on which ID data is extracted/retained | 🟡 Recommended | INFERRED | | Right to erasure / retention limits | GDPR Art. 17 or equivalent | Not met | No stated deletion policy for ID images post-verification | 🔴 Required | INFERRED | | Encryption of PII at rest | GDPR Art. 32 / common regulatory baseline | Partial | Private bucket ≠ confirmed encryption (SSE/KMS not stated) | 🔴 Required | INFERRED | | Access control & audit logging for PII access | GDPR Art. 32 / SOC2 CC family | Not met | No RBAC or audit trail on the review dashboard | 🔴 Required | INFERRED | | Breach notification readiness | GDPR Art. 33/34 or equivalent | Unknown | No stated incident-response process for a PII breach | 🟡 Recommended | INFERRED | | Vendor/sub-processor due diligence | GDPR Art. 28 / SOC2 vendor management | Unknown | No stated data processing agreement or vendor review for cloud storage provider | 🟡 Recommended | INFERRED | --- ## PHASE 6 — Review Integrity Check | Quality Check | Status | Note | |---|---|---| | All 6 STRIDE categories have at least one gap identified | ✅ | Spoofing (2), Tampering (2), Repudiation (2), Info Disclosure (3), DoS (1), Elevation (2) | | Every HIGH-priority gap has a full remediation plan | ✅ | 8 of 8 HIGH gaps covered (#1, 2, 3, 4, 5, 7, 11, 12) | | Trust boundary crossings are all mapped with a required control | ✅ | 5 crossings, each with an assigned control | | Coverage blind spots are distinct from the main gap register | ✅ | Blind spots describe adjacent risk left by *existing* controls, not new standalone gaps | | All INFERRED findings are labeled | ✅ | Labeled throughout | | Review stays focused on controls, not attack methods | ✅ | No exploitation detail included | **REVIEW CONFIDENCE: 55/100** — Confidence is moderate-low because the four stated inputs establish a clear trust-boundary skeleton, but almost every specific control (staff auth method, RBAC, logging, encryption-at-rest, retention policy) had to be INFERRED from best practice rather than confirmed from the system description. **Biggest coverage unknown:** Whether a separate backend database stores full names/metadata apart from the S3 image objects, and what authentication mechanism currently protects both end-user accounts and staff dashboard access. Either detail, if described, would substantially reshape the gap register (especially Gaps 1, 5, 8, 11). **Findings from inputs alone (STATED):** - HTTPS is used across the system - Basic file type validation exists on uploads - No virus/malware scanning currently exists - S3 bucket is set to private - Trust boundary chain: public internet → API gateway → app server → S3 → internal review dashboard - Data sensitivity: PII including government ID images and full names **Findings requiring implementation review to verify (VERIFY):** - Staff dashboard authentication mechanism and whether MFA exists - Whether "basic" file validation is extension-based or content-based - Whether S3 objects use server-side encryption (SSE/KMS) - Whether dashboard image access uses short-lived presigned URLs or static links - Existence of RBAC/role separation among reviewing staff - Existence of any audit logging for staff PII access or user upload events - Existence of a data retention/deletion policy for ID images - Existence of rate limiting, file size limits, or bot protection on upload endpoints - Existence of server-side ownership checks (IDOR protection) on document access endpoints