jobtrackingapp/docs/audits/2026-09-07

Jobjakt expanded production-readiness audit

Date: 2026-09-07. Source baseline: main, 7d641edc7bca866ccf06012897ba1d107c07e59f. Scope: the supplied 416 audit areas, including the architecture/security/product review they reference.

Verdict: needs work before a public paid launch. The application has substantial useful safeguards, but passing its normal suites does not establish safe concurrency, bounded resource consumption, complete billing lifecycle handling, or operational recovery. No P0 exploit was confirmed in this local assessment. That is not evidence that none exists. The P1 findings and unverified launch gates below remain blocking.

This is a dated assessment and executable overhaul plan. Application code, production configuration and existing databases were not changed. Tests used new synthetic local accounts and temporary SQLite databases. No production deployment, external provider integration test, email delivery, payment, dependency download, or live host inspection was performed. The adversarial harness blocks remote browser requests; the existing browser suite was run as written and is not an all-process network-isolation guarantee. The original August audit remains a historical record; its closed findings are not automatically reopened here.

Read the assessment

Deliverable	Contents
Findings and remediation	Priorities, source locations, root causes, reproduction, test expectations, implementation scope, staged rollout and detection
Source navigation	Clickable primary implementation files for F01–F21
Threat model and data lifecycle	Trust diagram, assets, attackers, privileges, abuse/rate limits, classification, retention and invariants
Resilience and failure answers	Failure and test matrices, transaction/retry decisions, all 50 “What happens if?” answers
Product, operations and quality gates	UX/a11y/polish, glossary, component ownership, critical paths, costs/capacity, runbooks and reusable checklists
416-area coverage index	Every requested area with its assessment destination and evidence boundary
Verification record	Commands, observed results, limitations, local artifact locations
Local adversarial harness	Reproducible synthetic API/browser observations; remote browser requests blocked

Evidence labels used throughout: Observed = executed during this audit; Source = implementation inspected, outcome inferred; Proposal = target design, not existing behavior; Needs runtime verification = missing live/staging/manual evidence. Coverage is not a pass certificate. Each test proves its exercised inputs only.

What works and should be preserved

• A modular ASP.NET Core API is appropriate. Controllers, services, EF Core, relational constraints and an isolated Python parser are sufficient building blocks; a microservice rewrite is unjustified.
• Tenant filters deny access without an owner. Sensitive cross-owner paths have dedicated tests; new direct CV GET/PUT/DELETE probes returned 404, and a normal user received 403 for admin audit access.
• Local sessions are checked server-side. Role changes revoke sessions, Pro authorization reads current roles, cookie mutations use a CSRF header, and canonical external-origin handling protects generated links.
• CV editing has a serialized save queue within one editor, visible save failures, retry, undo/redo, history, and navigation/unload warnings. Those controls do not prevent other tabs from overwriting it.
• Durable AI operations have stored status, owner-scoped idempotency, capacity checks, leases, retry limits, cancellation and entitlement/privacy rechecks. Preserve this investment; do not add Redis or a broker just to have a queue.
• Uploaded attachment handling stages/quarantines bytes and reconciles interrupted writes. Account deletion has stages, retries, session/public-link revocation and an independent restore tombstone ledger.
• Submitted application packages preserve rendered content and copies of attachments. This is stronger historical evidence than re-rendering a live CV against an edited profile.
• The parser already has subprocess isolation, bounded uploads, DOCX expansion limits, time limits, capacity limits and a constrained container. AI external-processing consent defaults off.
• CI includes full test suites, dependency locks, a tracked-secret scan, an SBOM generator and browser checks. The production deployment backs up before replacement and checks public readiness separately from liveness.

Current architecture and important qualifications

The frontend is React 19/MUI 7/React Router 7 in a Next.js 16 static-export shell. ASP.NET Core targets .NET 9 with EF Core 9. SQLite and MariaDB/MySQL are supported; PostgreSQL is not configured. PostgreSQL pool/index/search requests therefore translate into equivalent provider-specific reviews, not a recommendation to migrate databases. Redis and a general message broker are absent.

Compose defines frontend/nginx, backend, an isolated AI/parser sidecar and optional Ollama. MariaDB and the public TLS proxy are external operational dependencies. Backend/file/queue state shares the host failure domain. Private documents, provider credentials and the Data Protection key ring are accessible to the backend process. A single-backend deployment is an explicit constraint of process-local AI quota/admission locks.

The central architecture document still contains old controller/test counts, React Router v6 references, a claim that there is no CAPTCHA, and an outdated direction of Career Profile authority. Current code includes configurable Turnstile, relational career children, more controllers, and 753 passing backend tests. Use source and this dated assessment for these topics until that document is refreshed.

Launch blockers in execution order

1. Close exposed-ingress/SSRF and resource-consumption risks: F03, F04, F10, F11. Verify host firewall restrictions and introduce shared PDF admission before opening registration.
2. Prevent data loss and unsafe external side effects: F01, F02, F05, F07, F21. Add revision preconditions, operation idempotency, spreadsheet-safe export, correct timed-event round trips, and complete billing cancellation/reconciliation.
3. Prove recovery and privacy: F12, F13, F20, plus backup restoration, key custody, retention and secret rotation gates. Gate public operation on an actual restored recovery set and worker outage recovery.
4. Fix the builder accessibility and session/copy issues: F08, F09, F14–F18. Include builder routes in the release suite.

P1 means a credible security, data-loss, financial or host-availability risk within the described preconditions. P2 means a narrower reliability, usability, privacy-hardening or maintainability issue. A production evidence gap is a gate, not an invented vulnerability. No issue is marked fixed by this report.

Commercial assessment

My own CV: I would use a restricted personal installation after verifying its backup and limiting public/AI/billing surfaces. I would avoid simultaneous editing and keep an independent export. I would not yet recommend entrusting the only copy of someone's career documents to a public deployment.

100 paying users: not yet. The P1 findings, working deletion-versus-billing policy, a tested restore, actionable outage/backup alerts and accessible core editor must be resolved first. The existing architecture can plausibly serve this cohort after those corrections; this audit did not measure that capacity.

10,000 paying users: not demonstrated. Measure realistic concurrency, job-history/query volume, PDF capacity, storage growth and AI service time. Expect a managed/operated MariaDB recovery strategy, bounded workers, robust billing reconciliation and deployment redundancy to matter before adding application services. Move process-local quota admission into transactional database reservations before adding backend replicas.

Charge money today: I would not approve an unrestricted launch from this evidence. Product value is present, but billing deletion, concurrency safety, editor accessibility and operational recovery remain unfinished. Small closed testing with explicit limits is different from a readiness claim.

Measurable acceptance: all P1s have failing-before/passing-after tests; no known P0 remains; owner-isolation tests pass across read/write/download/background paths; stale writes produce a conflict with recoverable edits; all costly entry points have enforced limits; billing deletion and concurrent event reconciliation pass sandbox tests; restore meets the agreed RPO/RTO; normal core routes have no unexplained errors or serious/critical axe findings; core workflows work in both languages/themes and by keyboard. The operational owner must sign the external evidence gates in product-operations.md.