42 lines
5.8 KiB
Markdown
42 lines
5.8 KiB
Markdown
# Jobjakt Security Policy
|
|
|
|
## System and scope
|
|
|
|
Jobjakt manages private career profiles, CVs, letters, applications, correspondence and related account data. Review the repository-owned React/Next static-export UI, ASP.NET Core API, EF data and background processing, Python AI/document sidecar, browser extension, deployment/CI configuration and their trust boundaries. Architecture documentation describes nginx, MariaDB, private files and internal services; actual deployed exposure and identity must be verified separately. Retained SQLite and legacy document paths remain in scope while supported.
|
|
|
|
This policy supplies review context, not permission to run commands or test live targets. It does not certify existing controls. Root and component policies compose; nearest-path guidance takes precedence.
|
|
|
|
## Threat model and trust boundaries
|
|
|
|
Consider anonymous callers, two distinct authenticated owners, administrators, revoked or limited sessions, malicious document authors, incoming webhook senders and compromised external services. Treat route/body identifiers, uploaded files, HTML, job advertisements, external callbacks, logs and model output as untrusted.
|
|
|
|
Assets include canonical Career Profile facts/history, CV overrides and frozen revisions, application records, attachments, authentication/recovery material, provider tokens, billing entitlements, audit records and recoverable backups. Trace browser-to-API, API-to-database/files/workers, API-to-sidecar and provider callback/outbound fetch boundaries. Do not assume a role, a client UI flag or an internal-network label proves authorization.
|
|
|
|
## Security invariants
|
|
|
|
- Establish authenticated identity and owner scope before disclosing or changing private data. Caller-supplied owner IDs cannot replace server identity. Apply ownership to nested resources, lists/search, downloads, exports and background work, not only direct item reads.
|
|
- Enforce administrator and sensitive-operation permissions server-side, including self/last-admin restrictions. Session revocation, recovery, MFA and OAuth state/account-linking controls must preserve the intended identity boundary.
|
|
- Preserve canonical Career Profile ownership, null-as-inherit CV settings and immutable submitted/frozen snapshots. All applicable application/CV/letter writes must enforce existing revision preconditions and atomic persistence; stale operations must not partially commit or overwrite newer data.
|
|
- Bound untrusted document/upload/parser work. Validate type, size, owned paths and lifecycle state; reject traversal and unauthorized retrieval. Rendering/import must not execute active content, dereference unapproved URLs, expose local files or change another owner's data.
|
|
- Treat AI output as a proposal. Keep consent, entitlement, manual fallback, source/revision checks and explicit review/apply boundaries. Private content must not reach an unapproved model/provider; model or document text cannot authorize tool execution.
|
|
- Validate outbound destinations and redirects at network boundaries. Preserve job-provider rights/attribution and mailbox consent separately from sign-in identity. Validate webhook authenticity, identity binding and replay/idempotency where applicable.
|
|
- Preserve browser output encoding, safe HTML/rendering boundaries, origin/cookie/CSRF protections and validated return/navigation targets. UI visibility never substitutes for API authorization.
|
|
- Protect secrets, tokens and private document content in logs, diagnostics, browser bundles, exports and backups. Privacy deletion/retention must account for files, queued work and recovery copies; successful recovery claims require tested database/file/key consistency.
|
|
- Treat CI/deployment inputs and dependencies as supply-chain boundaries. Review least privilege, secret handling, provenance, image/runtime exposure and reversible recovery; test fixtures or historical reports do not prove production configuration.
|
|
|
|
## Reportable findings and severity context
|
|
|
|
Report reachable violations with attacker preconditions, affected assets and evidence. Cross-owner private-data disclosure/mutation, account takeover, privilege escalation, unsafe parser/rendering execution, exposed credentials and unauthorized external data transfer warrant impact-based investigation. Separate confirmed reproduction, reasoned likelihood and unverified assumptions.
|
|
|
|
Evaluate actual source/configuration and supported deployment modes. A package advisory, missing attribute or hypothetical path alone is not a reproduced exploit; equally, a passing mock test or limited deployment mitigation does not close a reachable issue. Record advisory/reachability and runtime evidence separately. Preserve failed, blocked, skipped and unexecuted checks explicitly.
|
|
|
|
## Exclusions and accepted risk
|
|
|
|
No vulnerability class, repository component or existing defect is implicitly suppressed. No new risk acceptance, severity downgrade or finding exclusion is granted by this policy. Historical deferred work and compatibility support remain reviewable.
|
|
|
|
Production, adjacent networks, real personal data and third-party systems are excluded from active testing unless separately and explicitly authorized. This execution restriction does not exclude review of repository-owned integration or deployment code. Synthetic local fixtures are distinct from approved staging and live-service qualification.
|
|
|
|
## Known limitations and qualification
|
|
|
|
The independent audit is incomplete. Source analysis, package checks, local fixtures, hosted CI, native accessibility, provider/model behavior, isolated staging and production recovery are separate evidence lanes. Final integrated security review follows relevant application changes. Baseline/deep/final scan results, cost allowance, staging scope and human release acceptance must be recorded separately; none is established by creating this file.
|