Our approach
Billing data is sensitive, so we keep the security model simple and enforce it on the server. This page lists practices that are implemented in Knock today, not aspirations.
Passwords
- Passwords are hashed with bcrypt before storage; plaintext passwords are never saved or logged.
- Password rules are validated on the server on every sign-up and reset.
Sessions
- Sessions use a signed token stored in an httpOnly cookie, so page scripts cannot read it.
- The cookie is SameSite=Lax, marked Secure in production and expires after 14 days.
- Signing out clears the session cookie.
Password reset
- Reset links expire after one hour.
- Only a hash of each reset token is stored, so a database leak does not expose usable links.
- The forgot-password flow does not reveal whether an email address has an account.
Access control
Knock has admin, staff and customer roles. Role checks run on the server for every request, not just in the interface, so hiding a button is never the only protection. Customers can only see their own subscriptions, invoices and payments.
Input validation and abuse limits
- Request bodies are validated against schemas on the server before they touch the database.
- Public forms such as the contact form use a honeypot field and per-IP throttling.
Infrastructure
Data is stored in MongoDB Atlas and transmitted over HTTPS. Secrets such as database credentials and API keys are kept in environment configuration and never in client code.
What we do not yet have
As a hackathon project, Knock has not undergone an independent security audit and does not hold SOC 2 or ISO 27001 certification. Two-factor authentication is not available yet.
Reporting a vulnerability
If you find a security issue, please tell us privately through the contact page, marked as security. Give us reasonable time to fix it before disclosing publicly, and avoid accessing data that is not yours. We appreciate good-faith research.