How access and credentials are handled
The controls that exist today, and an explicit list of the things this page does not claim.
Shiproom is early. What follows describes controls that are implemented, not an audited security posture. If you are evaluating Shiproom for work with a formal security requirement, read the last section first.
Reviewer access
Every project starts private. The reviewer URL only opens for someone holding a valid invite token. Invites are issued per label, can be listed with their open counts, and can be rotated or revoked; rotating replaces the link and the previous one stops working immediately.
Switching a project to public mode makes the reviewer URL open to anyone who has it. That is a deliberate, confirmed action, and the CLI requires an explicit acknowledgement before it takes effect.
Credentials at rest
Every bearer credential in the system — web session, device code, device token and invite token — is generated from 32 bytes of cryptographically secure randomness. Only a keyed HMAC-SHA256 hash of the credential is stored; the plaintext is never written to the database. Comparisons against a supplied secret are performed in constant time so they cannot be probed by timing.
Sign-in
Sign-in uses a six-digit code sent to your email address. Codes are generated with a cryptographically secure random number generator, stored hashed, expire after ten minutes, can be used once, and are limited to five attempts.
Web sessions are HttpOnly, Secure in production andSameSite=Lax, expire after 30 days, and are revoked on the server when you sign out rather than merely cleared from the browser.
CLI device authorisation
The CLI authorises through a device flow: it shows a code, you approve it in the browser, and the device token is delivered to the CLI exactly once. After that first retrieval only the hash remains. Authorisation state lives entirely in the database, so it survives a restart and does not depend on a request reaching the same server process twice.
Logging
Structured logs redact one-time codes, tokens, device tokens, passwords, cookies and authorization headers. One-time codes are never written to logs in any environment reachable from production; the configuration that would allow it is rejected at startup whenNODE_ENV is production.
What travels through the tunnel
Reviewer traffic reaches your application through Shiproom over HTTPS. The review widget is injected into HTML responses so reviewers can annotate the page. The widget's technical capture is bounded by design: failed requests are recorded as method, sanitised path, status, duration and timestamp, and never as headers, cookies, authorization values or bodies. See the privacy overview for the full list.
What this page does not claim
Stating these plainly is more useful than leaving them ambiguous. Shiproom does not currently claim, and you should not assume:
- Any compliance certification, including SOC 2, ISO 27001, HIPAA or PCI DSS
- A completed third-party penetration test or security audit
- End-to-end or zero-knowledge encryption of feedback content
- A guaranteed data-residency region
- A contractual uptime or support commitment
If your work requires any of the above, Shiproom is not the right tool for it yet. Please say so when you get in touch, so the answer is a straight one.
Reporting a vulnerability
Email [email protected] with enough detail to reproduce the issue. Please do not open a public issue for a security report, and please give a reasonable window for a fix before disclosing.