BrokenCode
brokencode

Security

Last updated 17 August 2026

This page describes how we protect your data and, just as importantly, what we have not built yet. We would rather you learn our limitations here than discover them during a procurement review.

Authentication and access

  • Passwords are hashed with bcrypt. We never store them in a readable form and cannot recover them.
  • You can sign in with Google or GitHub instead of a password. We request only your email address and basic profile.
  • Sign-in sessions use HTTP-only cookies, so page scripts cannot read your session token. Sessions expire after 7 days.
  • Calls between our web and API tiers use short-lived tokens minted per request, valid for 5 minutes, rather than forwarding your session.

Tenant isolation

Every query that reads assessment data is scoped to the company that commissioned it. A company can read the results of candidates it invited, and nothing else — not other companies’ candidates, and not candidates’ self-directed practice work. This is covered by automated tests that run on every change, specifically to stop a future edit from regressing it.

Authentication is deny-by-default: an endpoint is unreachable without a valid token unless it is explicitly marked public, so a new endpoint cannot be exposed by omission.

Data handling

  • Traffic is encrypted in transit.
  • Candidate answers sent to our AI grading provider carry no name, email, or account identifier.
  • Analytics is off until you consent, and is configured not to collect IP addresses.
  • Candidate contact details on an invitation are deleted automatically once the invitation expires unused.
  • Account erasure is self-service and deletes the free text you wrote rather than merely hiding it.
  • Request logs record the method, path and status code — not request bodies, so your answers do not end up in logs.

Application security

  • Every write endpoint validates its input against a strict schema and rejects unexpected fields outright.
  • Rate limiting is applied across the API, with tighter limits on sign-in, signup and AI grading.
  • Payment webhooks are verified by signature against the raw request body, using a timing-safe comparison.
  • Credit grants are idempotent, so a retried or duplicated payment callback cannot double-grant.
  • Configuration is validated at startup, so a missing or too-short secret stops the service rather than silently weakening it.
  • Secrets are held in the deployment environment, never in the repository.

What we have not built yet

An accurate list, current as of the date above:

  • No SOC 2 or ISO 27001 certification, and no third-party penetration test yet.
  • No multi-user company accounts — one login per company. No SSO or SCIM for customers, and no per-seat roles.
  • No multi-factor authentication, and no self-service password reset.
  • No audit log of who viewed or exported candidate results.
  • No bias or adverse-impact audit of the AI evaluator. We collect no demographic data, so one cannot currently be produced from platform data.
  • No human review of scores. Grading is fully automated — see the DPA for what that means for your obligations.

If any of these blocks a purchase, tell us — it helps us prioritise, and we would rather know than lose the deal quietly.

Reporting a vulnerability

Email brokencode.team@gmail.com with enough detail to reproduce the issue. We will acknowledge within 3 working days. Please give us a reasonable window to fix the issue before disclosing it publicly, and do not access, modify, or exfiltrate data belonging to anyone else while testing. We will not pursue legal action against researchers who follow this.


Questions about this document? See our grievance redressal contact.