Kinsugi security and accessibility

This page sets out how Kinsugi protects its platform and its users' data, and how the platform meets accessibility standards. Each section lists the controls in place today.

Sign-in and sessions

Accounts sign in with an email address and password and can add a second step. The operator dashboard also accepts GitHub sign-in. Every sign-in creates a server-side session that the browser holds through a protected cookie.

  • Passwords that users set must have at least 8 characters, with an upper-case letter, a lower-case letter, a number and a symbol.
  • Passwords are stored as bcrypt hashes with a cost factor of 12.
  • Sign-in is limited to 5 failed attempts per account and 40 per connection in each 15-minute window. Password reset requests are limited to 3 in each 15-minute window.
  • Accounts created through sign-up confirm their email address before use.
  • Sessions are stored on the server. The session cookie is HttpOnly, Secure and SameSite=Strict. A session ends after 7 days without use, or 30 days when the user chooses to stay signed in.
  • The secret that signs sessions is held only in the server's environment and is never written to the logs.
  • The operator dashboard has its own sign-in. Its stored credentials open only after a second PIN check, limited to 5 wrong attempts per user in each 15-minute window.
  • The dashboard's health report and its file vault open only to signed-in dashboard users.
  • Any account can turn on two-step sign-in with an authenticator app, using standard time-based codes, or with a six-digit code sent by email. After the password, the session grants nothing until the code is entered.
  • Authenticator secrets are stored encrypted with AES-256-GCM. Each account receives 10 single-use recovery codes, stored as bcrypt hashes.
  • Code entry is limited to 5 attempts per account in each 15-minute window. An emailed code expires after 10 minutes, and a used authenticator code is refused a second time.
  • The account holder is emailed whenever two-step sign-in is turned on or off, and an operator reset is recorded in the admin audit log.
  • The dashboard refuses a password sign-in from an operator account until that account has turned on two-step sign-in.

Input validation

Kinsugi checks what users send before it acts on it, and blocks the main forms of injection attack.

  • Every database query passes user data as bound parameters, kept apart from the query text. A code check blocks unchecked names in sort and group clauses.
  • A Content Security Policy with a fresh random value on every page load allows scripts only from Kinsugi, from scripts carrying that value, and from Google Analytics.
  • Error details from the server go to the logs, and pages show a plain message. A code check blocks any change that would show a raw error on a page.
  • Request bodies are limited to 10 MB, and sign-in requests to 1 MB, on every Kinsugi host.
  • Every route that accepts a request body checks it against a declared schema before any code acts on it, and refuses fields the schema does not name.
  • A code check refuses any POST, PUT or PATCH route registered without a declared schema ahead of its handler.

Encryption in transit and at rest

All traffic to Kinsugi is encrypted, and the database is reachable only from inside the server.

  • Kinsugi accepts HTTPS only and redirects plain HTTP to HTTPS. It accepts TLS 1.2 and 1.3 with forward-secret ciphers only.
  • Browsers are told to use HTTPS for two years on every Kinsugi domain (HSTS with preload). Certificates come from Let's Encrypt and renew automatically.
  • The database and the session cache listen on the server's own address only. The firewall admits web traffic on ports 80 and 443 and administration by SSH.
  • Server administration uses SSH keys only. Password sign-in to the server is turned off.
  • Credentials stored in the operator dashboard are encrypted with AES-256-GCM under keys derived with HKDF-SHA-256 from a master secret held in the server's environment.
  • The site chat stores no message on Kinsugi's servers.
  • The dashboard's generated-keys file is encrypted with AES-256-GCM under a key derived from the same master secret.

HTTP security headers

Responses from the application carry headers that tell the browser to apply its protections.

  • Content-Security-Policy: scripts run only from Kinsugi, with the page's random value, or from Google Analytics; styles also load from two public icon libraries; plugins and objects are blocked; framing is limited to Kinsugi; violations are reported to Kinsugi.
  • Strict-Transport-Security: two years, all subdomains, preload.
  • X-Content-Type-Options: nosniff. X-Frame-Options: SAMEORIGIN. Referrer-Policy: strict-origin-when-cross-origin.
  • Permissions-Policy turns off the camera, location, motion sensors and USB. Pages allow the microphone for Kinsugi and payment through Stripe.
  • The server's software name is removed from responses.

Dependency and patch management

Kinsugi checks its third-party packages before release and keeps the server's operating system patched.

  • Every deployment first audits the npm packages and stops on any known vulnerability at any severity, apart from the recorded exceptions. When the advisory service cannot be reached, the deployment goes ahead and logs a notice.
  • Each exception is recorded with an approval, a written reason and a review date. Two exceptions are open today.
  • Production installs leave out development packages and run no package install scripts.
  • The server installs operating system security updates automatically every day.

Logging and monitoring

Kinsugi records what happens on the platform and raises faults to the operator dashboard.

  • The web server logs every request to the site, the API and the dashboard with a request ID, and passes that ID to the application.
  • A refused request is logged with its route and the reason, never with the values sent.
  • Browsers report any blocked script or style to Kinsugi through the Content Security Policy.
  • A health service checks the database and the cache every 30 seconds and restarts either one after 3 failed checks.
  • Faults the platform finds in its AI and usage features are filed as typed reports on the operator dashboard, grouped by kind and counted.
  • When the application is unavailable, visitors see a maintenance page.
  • In production the application writes each log entry as a JSON record with its level, time and message.

Backup and recovery

Kinsugi backs up its database and stored files every night and keeps a copy away from the server.

  • Every night at 02:00 UTC the server backs up the database and the files users have uploaded, and keeps the last 7 nights. Only the server's administrator account can read the backups.
  • A copy command copies the newest backup to a machine away from the server and compares its checksum with the original.
  • A backup of the test platform was restored into a separate database, and its records matched the original.
  • A failed backup raises an alert on the health page and by email to the configured alert address.
  • Each deployment first backs up the application and the database, and stops if that backup fails. A failed deployment restores the application files from that backup.
  • One command restores the database from a chosen backup.

Incident response

Kinsugi has a written plan for security incidents and personal data breaches.

  • The plan names an incident lead and a communications lead, and sets a first response within 1 hour, at any time, when data is exposed or the platform is down.
  • It covers detection, containment, keeping evidence, notification and recovery. A serious incident gets a written review within 5 working days of closing.
  • A personal data breach that puts people's rights at risk is reported to the Information Commissioner's Office within 72 hours, and people at high risk are told without undue delay.
  • Security researchers can report a vulnerability through the contact published at /.well-known/security.txt.

Security testing

Kinsugi keeps a scripted security test suite in three tiers: checks of the code and its dependencies, scans of the running test platform, and active attack tests against it.

  • Each tier names its scanners, and a run fails on any high-severity finding.
  • The latest first-tier run covered the dependency audit and the lockfile integrity check, and found nothing beyond the two recorded exceptions listed under dependency management.

Accessibility

Kinsugi aims to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA.

  • An automated audit with axe-core checks the public pages against the WCAG 2.0, 2.1 and 2.2 A and AA rules, at desktop and mobile width.
  • The latest audit covered 14 public pages, this page included, and found no violations at either width.
  • Body text colours meet a contrast ratio of at least 4.5:1 against their backgrounds, and links inside text are underlined.
  • The home, pricing, sign-in and security pages were checked by hand with a keyboard. Every control was reachable with the Tab key and showed a visible focus outline.
  • Form messages carry role=alert for errors and role=status for confirmations, so screen readers announce them as they appear.

Personal data

Kinsugi gives account holders their data on request, deletes it on request, and records their consents.

  • Signed-in users can download the data Kinsugi holds about them, up to 3 times an hour.
  • A deletion request, confirmed with the account password, erases the account's personal data and its two-step sign-in record. Payment records are kept for the period the law requires and no longer identify the person.
  • Each consent a user gives or withdraws is recorded with the version it applies to.
  • Kinsugi uses these processors: Anthropic for AI replies, Stripe for payments, Plunk for email and Google Analytics for site analytics.

Hosting and data location

Kinsugi runs on DigitalOcean servers in Europe.

  • The production platform runs in DigitalOcean's Amsterdam data centre in the Netherlands. The UK recognises the European Economic Area as giving adequate data protection, so UK personal data may be held there.
  • The test platform runs in DigitalOcean's London data centre.
  • Kinsugi's AI features send the text of a request, with Kinsugi's instructions for the reply, to Anthropic's API.

Questions about this page: support@kinsugi.ai