This page describes safeguards currently implemented in KeyInOut. It is not a certification, penetration-test report or guarantee that vulnerabilities cannot exist.
01Workspace isolation
KeyInOut is a multi-tenant service. Operational database queries are designed to scope workspace records to the authenticated company. Administrative permissions are enforced server-side rather than relying only on hidden interface controls.
02QR design
QR labels use random opaque public identifiers rather than sequential database IDs. A QR identifier is not treated as authorisation to access private workspace data. Unauthenticated found-key pages are designed to expose only return information deliberately enabled by the workspace, not key names, holders, locations, hook positions, due dates or check-out status.
03Authentication and passwords
Passwords are stored using PHP's password-hashing facilities, using Argon2id when available. Password-reset, email-verification and invitation links use high-entropy tokens and store token hashes rather than reusable plaintext secrets where applicable. Login attempts are rate limited.
04Sessions and request protection
Authenticated sessions use hardened PHP session settings including HttpOnly cookies, SameSite protection, secure cookies on HTTPS and session-ID regeneration. State-changing application requests use CSRF protection. Sensitive authentication/token pages use restrictive caching/referrer behaviour.
05Database and application safeguards
Database access uses prepared statements with native PDO prepares. User-controlled output is escaped for HTML contexts. Critical key check-out/check-in operations use database transactions and row locking to reduce race conditions such as double check-out.
06Browser and transport protections
KeyInOut is intended to run over HTTPS and sends browser security headers including Content Security Policy, HSTS on HTTPS, frame restrictions and MIME-sniffing protection. Application assets are served locally rather than depending on third-party runtime CDNs.
07Data minimisation
QR codes do not embed key names, locations or holder details. Reminder emails intentionally minimise operational key information. User-facing workspace exports exclude password hashes and authentication-token hashes. Payment-card data is not currently collected by KeyInOut.
08Roles and auditability
Workspace roles separate owner/administrator capabilities from ordinary member access. Key handovers and returns are recorded in activity history, and administrative actions are logged where implemented. These records support accountability but do not replace a customer's own access-control procedures.
09Infrastructure and secrets
KeyInOut currently uses hosted infrastructure for the web application, database and transactional email. Sensitive mail configuration is designed to live outside the public web root. We continuously review and harden the production deployment configuration.
10Reporting a vulnerability
If you believe you have found a security issue, email security@keyinout.com with enough information for us to reproduce and assess it. Please avoid accessing data that is not yours, disrupting the service, using destructive testing, or publicly disclosing details before we have had a reasonable opportunity to investigate and address the issue.
For privacy matters rather than security vulnerabilities, use privacy@keyinout.com.