Security

• All traffic is served over HTTPS. HSTS is set with a two-year max-age, includeSubDomains and preload.
• A Content Security Policy is applied to every response. The admin portal — where sessions and personal data live — uses a per-request nonce with strict-dynamic, so an injected script cannot execute.
• frame-ancestors is set to none and X-Frame-Options to DENY, so the site cannot be framed for clickjacking.
• form-action is restricted to our own origin, which blocks exfiltration by rewriting a form’s target.
• X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy are all set.

• Content from the CMS is parsed into React elements rather than HTML strings. There is no dangerouslySetInnerHTML in the content pipeline, so stored cross-site scripting has no route to execution.
• All database access goes through a typed query builder with parameterised queries. There is no string-concatenated SQL.
• Every input is validated server-side against an explicit schema. Client-side validation exists for feedback only and is never trusted.
• Uploaded files are validated by extension, declared type and magic bytes, and are stored under a random key with no relationship to the uploader.
• Rate limiting is applied per IP and per email address on every public form, backed by the database so it holds across instances.

• Admin sessions use opaque random tokens. Only a SHA-256 hash is stored, so a database disclosure yields no usable sessions, and revocation is immediate.
• Sessions carry both an idle timeout and an absolute maximum lifetime, so a stolen cookie cannot be kept alive indefinitely by using it.
• Passwords are hashed with scrypt using per-password salts and interactive-strength cost parameters.
• Repeated failed sign-ins lock an account temporarily, and every failure path returns the same message and takes comparable time, so accounts cannot be enumerated.
• Authorisation is role-based and enforced server-side on every page and every mutation. Hiding a control in the interface is never treated as a permission check.
• Mutations additionally require a session-bound CSRF token and pass an origin check.

• IP addresses are never stored. Where abuse correlation is needed, a keyed one-way hash is stored instead.
• Résumés are held in private storage and are never publicly addressable. The only read path is an authenticated route that checks an explicit permission and writes an audit entry for every download.
• Secrets are server-side only. Nothing sensitive is exposed to the browser bundle, and this is enforced at build time rather than by convention.
• Consequential administrative actions are recorded in an append-only audit log, which deliberately excludes tokens, passwords and raw addresses.

• Database schema changes are applied through versioned migrations, never by hand.
• Errors are captured with an incident identifier that links a user-facing message to a server-side trace. Stack traces are never shown to visitors.
• Staging environments are excluded from search indexing at both the robots and meta level.

If you believe you have found a security issue, please tell us privately at hello@oryn.surf before disclosing it publicly. We will acknowledge your report and keep you informed while we work on it. We do not pursue researchers acting in good faith.