A STRIDE threat model for a claims-portal upload path. Seven reviewers.
The board concurs that the threat model exposes critical SSRF risk via the URL fetcher, high‑risk unsandboxed image/OCR processing, insecure long‑lived presigned URLs, absent malware scanning, and insufficient audit visibility. Immediate isolation, sandboxing, URL hardening, and improved logging are required.
The fetcher worker can download arbitrary URLs and follows up to 5 redirects without validating IP ranges, allowing access to internal services and metadata endpoints.
Raised by Principal Software Architect
ImageMagick and Tesseract run as raw subprocesses on uploaded files validated only by extension, exposing the worker to RCE through crafted payloads.
Raised by Security and Reliability Reviewer
Presigned S3 URLs are valid for 7 days, sent via plaintext email, and cannot be revoked, giving unauthenticated parties prolonged access to sensitive documents.
Raised by Product Delivery Lead
Uploaded documents are never scanned; reliance on endpoint protection on handlers’ laptops leaves the system vulnerable to zero‑day exploits delivered via documents.
Raised by Threat Modeling Specialist
Audit rows capture upload metadata but omit the original fetcher URL and lack granular document‑level ACLs, reducing traceability and fine‑grained protection.
Raised by AI Governance and Evaluation Reviewer
Majority view: critical
The decision is whether this security threat model is sufficient to support deployment or continued operation; it is not sufficient in its current form. The review identified critical SSRF exposure and multiple high-risk weaknesses that could enable internal-service access, remote code execution through uploaded files, and prolonged unauthenticated access to sensitive documents.
A score of 58/100 indicates serious deficiencies in the document's represented security posture, including missing or inadequate controls in core attack surfaces. Proceeding without addressing these findings would leave material, known exposures unresolved.
One reviewer assessed the SSRF issue as medium severity, while the majority assessed it as critical. This matters because the majority conclusion reflects the fetcher's ability to reach internal services and metadata endpoints without IP-range validation or outbound restrictions.
System: Document intake for the claims portal
Author: Security engineering
Review date: 2026-07-30
Method: STRIDE, informal
Authenticated customers upload supporting documents (photos, PDFs, occasionally
DOCX) to a claim. Files go to S3. A worker generates a thumbnail and extracts
text with an OCR library so claims handlers can search across attachments.
Handlers download originals through a signed URL.
An additional path exists: a customer may supply a URL instead of a file, and
our fetcher retrieves the document on their behalf. This was added for
insurers who host documents on their own portals.
Session hijacking is covered by the existing auth review. No new surface.
S3 objects are written once and never updated. Bucket versioning is on.
Every upload writes an audit row with user_id,
claim_id, SHA-256 of the
file, and timestamp.
Signed URLs are generated with a 7-day expiry so handlers can reference a
document across a working week without re-requesting. URLs are emailed to
handlers as part of the claim digest.
Bucket is private; only signed URLs grant access. There is no mechanism to
revoke a signed URL before expiry, but the window is short enough that we
consider this acceptable.
Upload size capped at 25MB. Rate limited to 20 uploads per claim per hour.
The OCR worker runs on a separate queue so a large batch cannot starve the API.
No user-supplied content is executed. Thumbnails are generated with ImageMagick
and OCR uses Tesseract, both invoked as subprocesses with the file path as an
argument.
open documents on managed laptops with endpoint protection, so the control
exists one layer out. Adding a scanner would add ~4s to the intake path.
.pdf, .jpg, .jpeg,
.png, .docx and reject everything else.
Content sniffing was considered
and deferred; the extension check has been sufficient in practice.
default. Customers occasionally supply shortened links and this keeps that
working.
is the current shared subnet acceptable given it only makes outbound calls?