Information Security Policy

This policy describes how KortzLab protects the information handled by this website and by the internal dashboard behind it.

It describes what is actually implemented. Where something is not in place, this document says so rather than implying otherwise.

---

1. Scope

This policy covers the KortzLab website, the private admin dashboard, the database behind them, and the file storage used for uploads.

Client projects that KortzLab builds are governed by the agreement for that project. Security practices applied to a client's own systems are set out in that project's scope, not here.

---

2. Access Control

• The dashboard has no public registration. Accounts are created by invitation from an existing administrator, or by a one-time provisioning step run directly against the server.
• Every account has a role, and every role has an explicit set of permissions.
• Authorisation is checked on the server for every request, not once at sign-in. Hiding a button in the interface is treated as presentation, never as a control.
• Requesting a record you are not entitled to see returns "not found" rather than "forbidden", so the system does not confirm that a record exists.
• Changing an account's role or suspending it signs that person out of every device immediately.

---

3. Authentication

• Passwords are hashed with Argon2id. We cannot read, recover or display a password; we can only replace it.
• A minimum password length is enforced, and new passwords are checked against a public breach corpus using a method that never transmits the password itself.
• Sessions are stored in the database. The cookie holds only an opaque token, is HttpOnly, Secure and SameSite=Lax, and cannot be read by JavaScript.
• Sessions expire both on inactivity and after an absolute maximum age, and can be revoked server-side at any time.
• Repeated failed sign-ins are throttled per address and per account, with a temporary lockout. Every sign-in response is identical whether or not the account exists, so the form cannot be used to discover who has an account.

---

4. Data Protection in Transit and at Rest

• All traffic is served over HTTPS, and the database connection requires TLS.
• Raw IP addresses are never stored. Where an address is needed for abuse protection or auditing, only a salted one-way hash is kept.
• Analytics visitor hashes use a salt that changes daily, so they cannot be used to follow someone from one day to the next.

---

5. Uploaded Files

Every uploaded file is treated as untrusted.

• Size, file extension, declared type and the file's actual byte signature are all validated on the server. A document renamed to look like an image is rejected.
• SVG files and archives are not accepted.
• Storage names are generated by the server. Nothing supplied by the uploader is used to build a storage path.
• Files are held in a private bucket. They are never served directly from storage; a request goes through the application, which checks authorisation first and then returns the file itself. Storage credentials and internal file paths never reach a browser.
• Uploaded files are never executed or interpreted, and are served with headers that prevent a browser from guessing a different type.

---

6. Application Security

• Every input from outside the application is validated on the server against an explicit schema. Validation in the browser exists for convenience only.
• Database access uses parameterised queries. Request data is never concatenated into a query.
• Fields a caller has no right to set — roles, ownership, timestamps, internal status — cannot be set by including them in a request.
• Content that renders as rich text is sanitised on output, so a stored script cannot execute in an administrator's browser.
• Every endpoint is rate limited, not just sign-in.
• The site sends a strict Content Security Policy along with the other standard security headers, and pages cannot be embedded in a frame on another site.
• Errors returned to a browser are generic. Technical detail stays in server-side logs, reachable through a reference code shown to the user.

---

7. Monitoring and Audit

• Administrative actions are written to an append-only audit log recording who did what, to which record, and whether it succeeded.
• The application has no ability to edit or delete an audit entry.
• Audit entries never contain passwords, tokens, credentials or file contents.
• Security-relevant events — failed sign-ins, authorisation denials, rate-limit triggers, rejected uploads — are logged.
• Logs redact sensitive values by field name before anything is written, rather than relying on each individual log call to remember.

---

8. Secrets

• Credentials live in environment variables held by the hosting platform, never in the source code.
• No secret is exposed to the browser. Configuration pages in the dashboard show whether an integration is configured, and never the values.
• A credential suspected of exposure is rotated.

---

9. Third Parties

This website depends on a small number of services: a database host, an object storage provider, and an email provider. Each is used only for its stated purpose, and each holds only the data needed for it.

There are no third-party advertising or analytics scripts on this website.

---

10. What This Policy Does Not Claim

To be clear about the limits:

• We hold no security certification and make no compliance claim.
• We have not published the result of an external penetration test.
• No system is immune to compromise. These controls reduce risk; they do not eliminate it.

We would rather state that plainly than imply an assurance we cannot evidence.

---

11. Reporting a Security Issue

If you believe you have found a vulnerability in this website, tell us before telling anyone else, and give us a reasonable chance to fix it.

• Email: support@kortzlab.pro

Please include enough detail to reproduce the issue. We will confirm receipt, keep you informed, and credit you if you would like to be credited.

Please do not access, modify or delete data that is not yours while testing, and do not run automated scanning that degrades the service for other people.

---

12. Incidents

If personal data is affected by a security incident, we will investigate the scope, take steps to contain it, and notify the people affected where we are required to do so or where the information would matter to them.

[TBD — legal review recommended] for the specific notification obligations that apply, which depend on jurisdictions that are themselves unresolved.

---

13. Changes to This Policy

We may update this policy as the system changes. The Last Updated date above reflects the most recent change.

---

14. Contact

• Email: support@kortzlab.pro
• Phone and WhatsApp: +971 54 297 5998

Related documents: the Privacy Policy sets out what is collected and why, and the Data Retention Policy sets out how long it is kept.