scan-receipts/SECURITY_VERIFICATION.md

SECURITY_VERIFICATION.md — Unabhängige Verifikation der 4 Security-Härtungsaufgaben

Projekt: Receipt Scanner App (Next.js 15 App Router, TypeScript strict, Alias @/ → src/) Verifikator: finaler Verifikations-Subagent (unabhängig, kein Blindvertrauen in Selbsttests der Implementierungs-Agents) Verifiziert am: 2026-08-17, 14:10 (lokale Zeit)

---

Gesamturteil: ALLE 4 AUFGABEN PASS ✅

Task	Status	Belege (Datei:Zeile)
1. Prompt-Injection-Block (AI/LLM)	PASS	Guard im komponierten System-Prompt; Sanitizer in allen 3 Provider-Pfaden; 27/27 Tests
2. KI-Nutzungslimits pro Nutzer/Tag	PASS	Daily-Cap 30/10, Pre-Check vor Extraktion, record nach Extraktion; 16/16 Tests
3. Request-/Upload-Größenlimits	PASS	16 Guard-Nutzungen (14× readJsonSized + 2× guardBodySize), 413 vor Body-Buffer; 13/13 Tests
4. Rate-Limiting Passwort-Resets	PASS	Burst 5/10min + 10/h auf reset, 60/h auf verify, 7 Routen limitiert; 20/20 Tests

---

Task 1 — Prompt-Injection-Block (AI/LLM) — PASS

Deliverables geprüft

• src/lib/ai/promptInjection.ts (NEU, 225 Zeilen):
  • INJECTION_GUARD (Z. 27–39): strikte deutsche Sicherheitsanweisung ("UNVERTRAUTE DATEN", Ignorieren von ignore/system prompt/instructions/tool calls, Schema-Zwang).
  • buildExtractionSystemPrompt() (Z. 44–46): hängt Guard an Basis-Prompt.
  • sanitizeExtractionOutput<T> (Z. 170–225): harte Grenzen — Strings gekappt (merchant.name 160, address 300, taxId 64, receiptNumber 128, lineItems.description 200, hospitality 200), Zahlen geklemmt (MAX_MONEY 1e9 Z. 51, MAX_QUANTITY 1e6 Z. 53, taxRate 0–100, confidence 0–1), Datum strikt YYYY-MM-DD inkl. realem Kalenderdatum (Z. 111–128), Uhrzeit strikt HH:MM (Z. 131–140), Enums via Zod-Schema mit Defaults (Z. 153–162), Währung nur A–Z ≤ 8 sonst EUR (Z. 146–150), Array-Caps (lineItems 200, taxBreakdown 10, Z. 55–57). Nicht-mutierend (neues Objekt, Z. 171).
• src/lib/ai/extractor.ts:
  • SYSTEM_PROMPT = buildExtractionSystemPrompt(BASE_EXTRACTION_SYSTEM_PROMPT) (Z. 159) — Guard in allen 3 Provider-Pfaden (OpenRouter Z. 372, Gemini Z. 420, OpenAI Z. 466: alle role: "system", content: SYSTEM_PROMPT).
  • sanitizeExtractionOutput({...object, validation: PENDING_VALIDATION}) direkt nach jedem generateObject: OpenRouter Z. 385, Gemini Z. 433, OpenAI Z. 479 (generateObject: Z. 367/415/461).

Test-Ergebnis

node_modules/.bin/sucrase-node tests/security/prompt_injection.test.ts → 6 Suites, 27 Tests, 27 Pass, 0 Fail, Exit 0 (Suites: System-Prompt-Komposition, String-Caps, Zahlen-Grenzen, Datum & Uhrzeit, Enums & Währung, Arrays & Integrität; inkl. Round-Trip-, Nicht-Mutations- und Erhalt-nicht-modellierter-Felder-Tests).

---

Task 2 — KI-Nutzungslimits pro Nutzer/Tag — PASS

Deliverables geprüft

• src/lib/ai/usage.ts (NEU, 156 Zeilen):
  • DAILY_SCAN_LIMIT = 30 (Z. 37), DAILY_GUEST_SCAN_LIMIT = 10 (Z. 40), HOURLY_SCAN_LIMIT = 120 (Z. 47, dokumentierend).
  • checkDailyUsage(key, limit, now) (Z. 93–115): nicht-mutierender Pre-Check, now injizierbar, kaputte Konfiguration → "allow".
  • recordUsage(key, units, now) (Z. 123–146): 24h-Fixed-Window (DAILY_WINDOW_MS Z. 34), Units-Ceil (Seiten zählen), defensive Normalisierung.
  • usageKeyForUser/usageKeyForGuest (Z. 149–155): Formate ai:user:<id> / ai:guest:<bucket>.
  • Overshoot- und Deployment-Caveat (In-Memory, pro Instanz) dokumentiert (Z. 17–31).
• src/app/api/scan/route.ts — Verdrahtung (Reihenfolge im POST verifiziert):
  1. requireCsrf (Z. 53) — CSRF vor allem.
  2. guardBodySize(req, MAX_UPLOAD_BYTES) (Z. 58–59) — Size-Guard vor req.formData() (Z. 64) und vor dem Daily-Check.
  3. IP-Rate-Limit scan:ip: (Z. 61).
  4. Daily-Pre-Check (Z. 91–103): usageKey = user ? usageKeyForUser : usageKeyForGuest; checkDailyUsage → 429 { error: "daily_scan_limit_reached", limit, retryAfter } mit Retry-After (Z. 98–99) — vor dem dbAvailable-Block (Z. 105) und vor der Extraktion (Z. 199–228).
  5. Extraktion (Z. 199–228), danach recordUsage(usageKey, document.pageCount) (Z. 284) — mit document.pageCount (Seiten zählen als AI-Calls).
  • Bestehende CSRF-, Size-, Quoten-Logik intakt: User/Free-Quota (Z. 109–133), Guest-Quota (Z. 134–171), DB-Counter (Z. 259–279).

Test-Ergebnis

node_modules/.bin/sucrase-node tests/security/ai_usage_cap.test.ts → 5 Suites, 16 Tests, 16 Pass, 0 Fail, Exit 0 (Pre-Check-Semantik, Zähler & Fensterstart, Fenster-Reset über injiziertes now, Key-Isolation, Overshoot & Konfiguration).

---

Task 3 — Request-/Upload-Größenlimits — PASS

Deliverables geprüft

• src/lib/http/requestSize.ts (NEU, 72 Zeilen):
  • contentLengthExceeded (Z. 11–19): Header-only, malformed/negativ → false (wird nachgemessen).
  • guardBodySize (Z. 27–30): 413 { error: "request_too_large", maxBytes } vor Body-Buffer.
  • readJsonSized (Z. 41–71): Content-Length → 413; Parse-Fehler → 400 invalid_json; Nachmessung (serialisierte Länge) → 413.
• src/lib/limits.ts: MAX_UPLOAD_BYTES = 10 MB (Z. 11), MAX_JSON_BODY_BYTES = 1 MB (Z. 14), MAX_FORM_FIELDS = 20 (Z. 17), MAX_FORM_FILES = 20 (Z. 20).
• Gehärtete Routen (grep über src/app, 16 Nutzungen ≥ 15 gefordert):
  • guardBodySize (2): api/scan Z. 58 (vor req.formData() Z. 64); webhooks/stripe Z. 90 (vor req.text() Z. 93, Signatur gegen raw body — Buffer-Schutz bestätigt).
  • readJsonSized (14): auth/login Z. 30, auth/signup Z. 63, auth/forgot-password Z. 40, auth/reset-password Z. 30, auth/resend-verification Z. 40, auth/change-password Z. 54, api/receipts POST Z. 190, export/csv Z. 15, export/excel Z. 15, export/pdf Z. 15, onboarding Z. 29, checkout Z. 27, waitlist Z. 23, license/verify POST Z. 135.
  • Stichproben gelesen (onboarding, export/csv, checkout, license/verify, receipts): alle im POST-Handler, nach CSRF, vor Body-Nutzung/DB, !parsed.ok → parsed.response-Muster konsistent.

Test-Ergebnis

tests/security/request_size.test.ts → 3 Suites, 13 Tests, 13 Pass, 0 Fail, Exit 0.

Ausführungs-Notiz (transparent dokumentiert): Die Datei importiert src/app/api/scan/route, das intern @/-Aliase und src/lib/image/processor.ts nutzt. Beides blockiert Plain-sucrase-node:

1. @/-Alias → gelöst per Module._resolveFilename-Shim (Muster aus password_reset_rate_limit.test.ts).
2. processor.ts nutzt import.meta.url (Z. 379, ESM-only) → unter CJS-Transpilern nicht ladbar (Node-24-Erkennung wirft exports is not defined in ES module scope). Keiner der 13 Tests ruft processReceiptDocument auf (der 413 feuert vor jeder Verarbeitung; der Boundary-Test beweist genau das über die echte Route: formData-Fehler bei Route.ts:64 → 500 statt 413). Daher wurde im temp. Wrapper nur die Import-Kette dieses einen Moduls durch ein Stand-in gleicher Export-Surface ersetzt. Der Wrapper (node .verify_request_size.cjs mit sucrase/register) wurde nach Abschluss gelöscht; die Testdatei selbst blieb unangetastet.

---

Task 4 — Rate-Limiting Passwort-Resets — PASS

Deliverables geprüft

• src/app/api/auth/reset-password/route.ts:
  • Burst-Limit reset:burst:ip:<ip> 5/10min (Z. 46–47) zusätzlich zu IP 10/h reset:ip:<ip> (Z. 49–50); 429 via rateLimited() aus http.ts (Import Z. 4).
• src/app/api/auth/verify/route.ts:
  • IP 60/h verify:ip:<ip> (Z. 32), Überschreitung → Redirect status=rate_limited (Z. 33) — Redirect-Vertrag der GET-Route bleibt intakt.
• Coverage-Matrix (grep rateLimit unter src/app/api/auth/ → 23 Treffer in 7 Routen; alle 429 via rateLimited() aus src/lib/auth/http.ts, Z. 21–26):

  Route	Limits	Beleg
  forgot-password	IP 5/h forgot:ip: + Email 3/h forgot:email:	Z. 52–53, 58–59
  reset-password	Burst 5/10min reset:burst:ip: + IP 10/h reset:ip:	Z. 46–47, 49–50
  change-password	IP 10/15min change:ip: (bestand)	Z. 74–75
  resend-verification	IP 5/h resend:ip: + Email 3/h resend:email:	Z. 52–53, 58–59
  login	IP 20/15min login:ip: + Email 10/15min login:email:	Z. 42–43, 51–52
  signup	IP 5/h signup:ip: + Email 3/h signup:email:	Z. 75–76, 91–92
  verify	IP 60/h verify:ip:	Z. 32

• Keine Auth-Route ohne Limit, die einen Body mit Passwort/Token verarbeitet: alle 6 Passwort/Email-POST-Routen gelistet; google/callback (GET, OAuth-Code+State mit State/Verifier-Cookie + constant-time Vergleich, Z. 60–62) und verify (GET, jetzt limitiert) sind keine Passwort-Body-Routen.
• Kanonische Implementierung src/lib/security/rateLimit.ts: Fixed-Window (Z. 59–78), clientIp vertraut nur dem Proxy-angehängten rechten x-forwarded-for-Eintrag + x-real-ip, nie rohen Client-Header (Z. 100–115), resetRateLimits für Tests (Z. 81–83).

Test-Ergebnis

node_modules/.bin/sucrase-node tests/security/password_reset_rate_limit.test.ts → 4 Suites, 20 Tests, 20 Pass, 0 Fail, Exit 0 (Fixed-Window-Semantik, die 7 Produktions-Budgets, 429-Helper, Client-IP-Extraktion; enthält den @/-Shim).

---

Gesamt-Test-Ergebnisse

Datei	Suites	Tests	Pass	Fail	Exit
tests/security/prompt_injection.test.ts	6	27	27	0	0
tests/security/ai_usage_cap.test.ts	5	16	16	0	0
tests/security/password_reset_rate_limit.test.ts	4	20	20	0	0
tests/security/request_size.test.ts (via temp. Shim-Wrapper)	3	13	13	0	0
tests/e2e/auth_security.test.ts (Regressions-Check, via temp. Shim-Wrapper)	7	38	38	0	0
Summe	25	114	114	0	—

Regressions-Check bestanden: Die Auth-Änderungen (readJsonSized-Umbau + Rate-Limit-Einbau) haben keine bestehende Auth-Logik (Email-Normalisierung, Passwort-Hashing, Token-Handling, Fehler-Vokabular) kaputt gemacht.

---

TypeScript (Step C)

• Gesamtlauf: node node_modules/typescript/bin/tsc --noEmit -p tsconfig.json → Exit 0, 0 Fehler (2× verifiziert: normal und erzwungen mit --incremental false gegen den Buildinfo-Cache).
• Attribution: Keine Fehler in unseren Dateien. Die bekannte externe Datei src/lib/http/sensitivePaths.ts (anderer, parallel laufender Agent) ist inzwischen syntaktisch sauber (per typescript.transpileModule verifiziert) — kein Fehler mehr zuzuschreiben.
• Scoped-Kompilierung nicht nötig (Gesamtlauf sauber; die im Auftrag genannte Bedingung "falls Gesamtlauf nicht sauber" ist nicht eingetreten). Alle 4 neuen/geänderten Lib-Dateien (promptInjection.ts, usage.ts, requestSize.ts, limits.ts) und alle geänderten Routen sind Teil des grünen Programms.

---

Build (Step D, best effort)

• Ergebnis: NICHT AUSFÜHRBAR in dieser Sandbox — kein Codefehler.
• npm run build → next build bricht sofort ab mit [Error: spawn EPERM] { errno: -4048, syscall: 'spawn' } beim Start der Next.js-Worker (jest-worker mit gepiptem Stdio). Das ist die dokumentierte Sandbox-Grenze (Kindprozess-Spawns mit Pipe-Stdio sind geblockt; Escalation ist in dieser Session deaktiviert).
• Attribution: Umgebungslimit, nicht unsere Dateien. Statischer Ersatznachweis: vollständiger tsc --noEmit-Lauf grün (Exit 0). Hinweis: build_err.txt vom 16.08. zeigt, dass ein früherer Lauf außerhalb dieser Grenze bis "Compiled successfully in 13.0s" kam und danach an einem .next/server/middleware-manifest.json scheiterte (Domäne middleware.ts des anderen Orchestrators, stalelog von gestern — heute nicht reproduzierbar, da der Build hier gar nicht startet).
• Empfehlung an den Orchestrator: Build außerhalb der Datei-Sandbox (bzw. mit erweiterten Rechten) final ausführen und eventuelle middleware/schema-Fehler dem zuständigen Agent attribuieren.

---

Befunde & Anmerkungen (kein FAIL)

1. MAX_FORM_FIELDS/MAX_FORM_FILES (limits.ts Z. 17/20) sind definiert, werden aber von keiner Route ausgewertet. Das erfüllt die Deliverable-Spezifikation (Konstanten existieren); als Defense-in-Depth-Lücke dokumentiert. Die Scan-Route liest exakt ein Feld (file), der 10-MB-Content-Length-Guard ist die primäre Kontrolle. Kein Fix erforderlich für "verifiziert", optional nachrüstbar.
2. In-Memory-Limiter (usage.ts Z. 63–73, security/rateLimit.ts Z. 35–45): pro Instanz; beide Dateien dokumentieren die Deployment-Caveat (N Replicas multiplizieren das Budget; Restart leert Buckets). Für Single-Instance-Deployment akzeptabel — vor Skalierung auf Redis/Postgres umstellen.
3. Test-Infrastruktur-Hinweis (transparent): request_size.test.ts läuft nicht nativ unter sucrase-node — Ursache Nr. 1 ist der @/-Alias (bereits erwartet), Ursache Nr. 2 (neu entdeckt) ist import.meta.url in src/lib/image/processor.ts, das unter CJS-Transpilern grundsätzlich nicht ladbar ist. Lösung per temp. Wrapper (Alias-Shim + Import-Ketten-Stand-in für das nie aufgerufene Processor-Modul); Testdatei unverändert.
4. verify-Route antwortet per Redirect status=rate_limited statt 429 — bewusst so (GET-Redirect-Vertrag), im Code dokumentiert (Z. 25–33).

---

Verifiziert am 2026-08-17, 14:10 — Gesamteinschätzung

ALLE 4 AUFGABEN PASS. 114/114 Tests grün (5 Suiten-Dateien, 25 Suites), vollständiger TypeScript-Check (inkl. aller 4 neuen Lib-Dateien und aller gehärteten Routen) mit Exit 0 und 0 Fehlern, Code-Audit mit Belegen je Task. Der Build konnte nur wegen der Sandbox-Grenze (spawn EPERM) nicht ausgeführt werden — kein Hinweis auf einen Codefehler in den verifizierten Dateien. Das Projekt gilt damit als "verifiziert" für den Scope dieser 4 Security-Härtungsaufgaben.

Keine Produktionsdatei wurde verändert; alle Temp-Artefakte (Wrapper, Logs) wurden nach Abschluss gelöscht.