Hashed passwords
Account passwords are stored as bcrypt hashes. Your original password is not recoverable through the application.
TRUST STARTS WITH CLARITY
Security, without the fine-print claims.
A practical view of the controls in this project and the boundaries of the current MVP.
Protected browser sessions
Browser sessions use HttpOnly cookies. Authentication credentials are not stored in browser localStorage. State-changing browser requests enforce same-origin checks.
Single-use email links
Verification and password-reset tokens are hashed in the database, expire after 15 minutes, and can be used once. Account access requires verified email.
Scoped API access
API requests authenticate through a key header. Manage and revoke keys from your account, and keep keys out of public URLs and client-side bundles.
Server-side permissions
The backend checks account status and role. Administrative actions require an administrator account; a hidden menu is not the security boundary.
Encrypted mail transport
Account email is sent through an authenticated connection over HTTPS. Direct SMTP, when configured separately, requires certificate-verified TLS.
Keep your side of the connection safe.
- Store API keys in a server-side secret store or private environment.
- Use HTTPS for a public deployment. Local HTTP is a development exception.
- Revoke exposed keys and use a unique account password.
- Redact tokens, credentials, and private URLs before sharing logs.
What this page does not certify.
No third-party security certification, independent audit, contractual SLA, or public-deployment readiness is claimed here. External scraping and crypto checkout are simulated. Real authentication and email verification do not make those adapters live.
View service status →KEEP BUILDING