Risks and Assumptions

Risks, obstacles, assumptions, and migration concerns identified during the system design. Items may be out of scope for implementation but are recorded for project-level tracking.

Risks

ID	Risk	Likelihood	Impact	Mitigation	Status
R-001	HEIC/HEIF browser support gaps. Not all browsers support HEIC/HEIF natively. Safari supports it; Chrome/Firefox may require client-side conversion libraries (e.g., `heic2any`).	Medium	Medium	SPA detects browser capability at runtime. If HEIC is not natively supported, attempt client-side conversion to JPEG before entering the editor. If conversion fails, show a format-specific error. Acceptance of HEIC is in scope (SD-09) but browser support confirmation is required before implementation.	Open — requires browser testing matrix
R-002	Orphaned image objects accumulate. If the user uploads an image (presigned POST succeeds) but never submits the entity form, the object remains in S3 indefinitely. At projected volumes this is negligible (~$0.11/month for 10% orphan rate), but could grow over time.	Low	Low	S3 lifecycle rules on a staging prefix (if adopted) or periodic scan job comparing S3 objects against entity image URLs. Deferred — the cost at projected volumes does not justify the complexity. See SD-04 (retention policy deferred).	Accepted — monitor, implement cleanup later
R-003	CORS restrictions on external URLs are broader than expected. If most external image URLs block cross-origin requests, the BFF fetch-url endpoint becomes the primary path rather than a fallback. This increases BFF load and latency.	Medium	Low	BFF fetch-url endpoint is designed for this case. Rate limiting (OAM-C-004) prevents abuse. Monitor BFF fetch-url usage vs. direct SPA fetch to assess real-world CORS restriction rates using Sentry (available in the BFF) — track fetch-url call frequency, latency, and error rates. For CDN-to-SPA cross-origin (canvas editing of existing CDN images), CloudFront CORS Response Headers Policy is required — see FD-17, infrastructure#439.	Open — monitor via Sentry after launch
R-004	Presigned POST policy condition limitations. S3 presigned POST policy conditions cannot enforce image content at the byte level (only Content-Type header, which can be spoofed). A malicious or misconfigured client could upload non-image content with an `image/*` Content-Type.	Low	Medium	Defense-in-depth: (1) Presigned POST Content-Type condition is the first barrier. (2) Backend HEAD request verifies the object exists but cannot inspect content. (3) CDN serves `X-Content-Type-Options: nosniff` to prevent browser MIME sniffing. (4) Future enhancement: post-upload Lambda that inspects magic bytes and quarantines non-image content.	Accepted — current mitigations sufficient for MVP
R-005	Signed cookie exfiltration. If a signed cookie is exfiltrated (e.g., XSS, browser extension, shared computer), an attacker can access the tenant’s images until the cookie expires.	Low	High	Short cookie TTL (30 min default) limits the breach window. `HttpOnly` flag prevents JavaScript access (mitigates XSS). `Secure` flag prevents transmission over HTTP. `SameSite=Lax` prevents CSRF-style exfiltration. Key rotation capability limits the impact of a compromised signing key. See cdn-access-control.md for full threat analysis.	Accepted — multiple layers of mitigation
R-006	Large image files on slow connections. Uploading a 10 MB image over a slow connection may time out the presigned POST (5-minute expiry) or cause poor UX.	Low	Medium	Auto-compression (FR-009) reduces file size before upload. Presigned credential expiry is configurable (OAM-C-002). The SPA can detect upload progress and show a progress indicator. Future enhancement: multipart upload for files >5 MB.	Accepted — auto-compression is primary mitigation
R-007	BFF SSRF vulnerability. The BFF reachability/fetch endpoints make outbound HTTP requests to user-provided URLs. If SSRF protections are incomplete, an attacker could probe internal infrastructure.	Medium	High	BFF-FR-007 mandates SSRF protection: reject private IPs, localhost, non-HTTPS, managed storage URLs. DNS resolution must be validated post-resolution (not just hostname). Use allowlist for external domains if needed. Security review of the SSRF implementation is critical.	Open — requires security review during implementation

Assumptions

ID	Assumption	Implication	Risk if Wrong
A-001	Product images are sensitive data. Customers may upload R&D prototype images that must not be leaked to unauthorized parties or other tenants.	CDN access requires CloudFront signed cookies scoped to the active tenant (TD-11). Cookies are short-lived (30 min default) with proactive renewal (TD-12). See cdn-access-control.md for the full security analysis.	N/A — this is a constraint, not an assumption.
A-002	Each tenant stores at most ~1,000 images in the initial deployment. Total storage ~50 GB for 100 tenants.	S3 and CloudFront costs are negligible (~$22/month total). No need for per-tenant quotas or storage alerts in MVP.	If storage grows significantly (e.g., 10x), per-tenant quotas and cleanup automation become necessary. Monitor via OAM-P-005.
A-003	The existing `imageUrl: URL?` field on the Item entity is the only image field in MVP. Future entity types will reuse the same generic infrastructure.	Single `ImageFieldConfig` for Items (1:1 square). No multi-image support needed.	If an entity type requires multiple image fields or non-square ratios, `ImageFieldConfig` already supports this — no design changes needed, only configuration constants.
A-004	Modern browsers used by target personas support `<canvas>`, `FileReader`, `Clipboard API`, and `fetch`.	Client-side image processing (crop, rotate, compression) is feasible.	If a user’s browser lacks Canvas support (very unlikely for modern browsers), image editing features degrade. SPA should detect and disable editor features gracefully.
A-005	The BFF URL reachability check + fetch proxy handles the majority of CORS-blocked external URLs.	SPA tries direct fetch first; BFF is a fallback. Most uploads are file/clipboard (no CORS involvement).	If direct fetching never works (all URLs CORS-blocked), every URL input routes through BFF. This is handled (BFF-FR-005) but increases BFF load.
A-006	The existing bitemporal persistence model provides sufficient history tracking for image changes. No image-specific versioning or history UI is needed in MVP.	Image history is visible through entity version history. No separate “image gallery” or “image versions” view.	If users need to browse previous images specifically, a history UI would need to be built. The bitemporal data supports this query.

Migration Concerns

ID	Concern	Impact	Recommendation
M-001	Existing `imageUrl` values. Some Items may already have `imageUrl` values pointing to external HTTPS URLs (set via CSV import or direct API). With TD-05, the Backend now validates that all `imageUrl` values match the CDN pattern. Existing external URLs would fail validation on next entity update.	Medium — affects entities with external image URLs	Option A (recommended): Grandfather existing URLs. The Backend validation should apply only to new image URL values set through the upload workflow. Entity updates that do not change `imageUrl` should not trigger validation. Option B: Migration script to fetch-and-store existing external URLs. More complete but requires one-time migration infrastructure. Decision deferred to implementation planning.
M-002	CSV import `imageUrl` column will break. The CSV import currently accepts any HTTPS URL in the Image column and stores it as-is. Once Backend URL validation (TD-05) is enforced, CSV imports containing external HTTPS URLs will fail — the Backend rejects any `imageUrl` that does not match the system-managed storage pattern. This breaks the existing CSV round-trip for rows with external image URLs. CSV image handling is deferred to a separate session (SD-03), but the breakage will be immediate once this feature ships. A follow-up project to redesign CSV image import (fetch-and-store during import, or accept-and-migrate) must follow closely after the initial implementation.	Medium — breaks existing CSV import behavior for rows with external image URLs	Immediate mitigation: The grandfathering approach in M-001 may partially address this if CSV import is treated as an entity update that preserves unchanged `imageUrl` values. However, new CSV imports with external URLs will still fail. Required follow-up: A redesign of CSV image import must be planned as a fast-follow project. Until then, CSV users must use system-managed URLs or leave the Image column empty. The use case spec (`REF::ITM::0006::0005.FS`) has been updated to reflect this constraint.
M-003	No existing CloudFront distribution for assets. The infrastructure currently has no S3-origin CloudFront distribution. The API CloudFront construct exists but is HTTP-origin only (no caching, all methods). A net-new CDK construct is needed.	Low — well-understood AWS pattern	New CDK constructs (`ImageAssetBucket`, `ImageAssetCdn`) follow established patterns. The `UploadBucket` construct provides a reusable template. Infrastructure changes should be deployed before Backend changes.
M-004	Cross-stack export dependencies. New infrastructure (bucket, CDN, presigning role) exports values consumed by the Operations CloudFormation. Deployment ordering must be: infrastructure first, then operations. This is the existing deployment pattern for the CSV upload bucket.	Low — follows existing pattern	Same deployment orchestration as existing upload bucket. Document the dependency in deployment runbook.

Out of Scope (Recorded for Future Tracking)

These items were identified during system design but are explicitly out of scope for this implementation. They are recorded here to prevent information loss.

Item	Reference	Notes
Image retention/cleanup policy	SD-04	GitHub ticket to be created during implementation.
Cross-tenant image sharing	SD-05	Requires legal review. Not in this version.
Background removal	SD-02	Future enhancement. Not in V1.
Bulk CSV image handling	SD-03	Separate session.
Mobile camera UX details	SD-16	Future mobile UX session.
Per-tenant storage quotas	A-002	Not needed at projected volumes. Monitor and add if growth warrants.
Post-upload content validation (magic byte inspection)	R-004	Lambda-based. Future enhancement for defense-in-depth.
Per-image signed URLs (more granular than cookies)	R-005	If cookie-level tenant scoping is insufficient (e.g., per-object access control needed). Current signed-cookie approach is tenant-level.
Image processing pipeline (resize, thumbnailing)	Prior design: Out of Scope	CDN serves original images. CSS scaling for thumbnails.
BFF/SPA endpoint path pluralization consistency	Audit #5, #847	New endpoints use singular (`/api/item/<itemEId>/image-upload-url`); existing entity update uses plural (`/api/items/<itemEId>`). Standardization to singular convention is tracked in #847. Scenario diagrams retain the current inconsistency with a caution note. Fix in a follow-up project.