Security

Keeping your data safe is our top priority. Here is how we protect you.

Last updated: April 15, 2026

How We Protect Your Account

HTTPS Everywhere

All traffic between your device and our servers is encrypted using TLS 1.2 or higher. Plain HTTP requests are automatically redirected to HTTPS. HTTP Strict Transport Security (HSTS) is enforced so your browser never falls back to an insecure connection.

Password Security

Passwords are never stored in plain text. We use bcrypt with a high work factor (cost 12) to hash every password before it reaches our database. This means even if our database were compromised, passwords would remain computationally infeasible to crack.

Short-Lived Session Tokens

Authentication is handled with JSON Web Tokens (JWT). Access tokens expire in 15 minutes; refresh tokens expire in 7 days. Both are stored exclusively in HttpOnly, Secure, SameSite=Strict cookies โ€” inaccessible to JavaScript, protecting you from cross-site scripting (XSS) attacks.

Multi-Factor Authentication

We support email-based one-time codes (OTP) as a second factor during login. Enabling MFA significantly reduces the risk of account compromise even if your password is leaked.

Rate Limiting

All API endpoints are rate-limited via Redis-backed throttling. Login and password-reset endpoints have stricter limits to prevent brute-force and credential-stuffing attacks.

Input Sanitisation

Every piece of user-supplied input is validated with class-validator DTOs on the backend and sanitised by a global middleware before processing. This protects against injection attacks and cross-site scripting (XSS).

Database Security

Our MongoDB database uses encryption at rest (AES-256) and in transit (TLS). Role-based access control ensures that only the application service account can read or write data. Admin access requires multi-factor authentication and IP allowlisting.

Secret Management

All secrets โ€” API keys, database credentials, JWT signing keys โ€” are managed via environment variables and CI/CD secret stores. They are never hard-coded in source code or committed to version control.

Security Headers

Our API server uses Helmet.js to set a strict Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy. Our Next.js frontend applies matching security headers via next.config.js.

Dependency Auditing

We pin all package versions explicitly and run automated vulnerability audits (pnpm audit) on every build. Critical security updates are applied within 48 hours of disclosure.


How You Can Stay Safe

Security is a shared responsibility. Here are steps you can take to protect your account:

  • Use a strong, unique password for your Too Fresh To Waste account โ€” do not reuse passwords from other services.
  • Enable Multi-Factor Authentication (MFA) in your account settings.
  • Be cautious of phishing emails that appear to be from Too Fresh To Waste. We will never ask for your password via email.
  • Keep your device's operating system and browser up to date to benefit from the latest security patches.
  • Log out of your account when using a shared or public device.
  • If you suspect your account has been compromised, change your password immediately and contact us.

Responsible Disclosure

We take security reports seriously. If you discover a vulnerability in our platform, we encourage you to disclose it responsibly so we can fix it before it is exploited.

How to Report a Vulnerability

  1. Email support@toofreshtowaste.com with the subject line: "Security Vulnerability Report".
  2. Describe the vulnerability in detail โ€” include steps to reproduce, potential impact, and any supporting screenshots or proof-of-concept code.
  3. Do not publicly disclose the vulnerability until we have had a reasonable opportunity to investigate and remediate it (typically 90 days).

Our Commitment

  • We will acknowledge your report within 3 business days.
  • We will keep you informed as we investigate and fix the issue.
  • We will not take legal action against researchers who report vulnerabilities in good faith and follow this policy.
  • We recognise reporters publicly (with their consent) once a fix has been deployed.

Out of Scope

The following are outside the scope of our disclosure programme:

  • Denial-of-service (DoS/DDoS) attacks
  • Social engineering or phishing of our employees
  • Attacks requiring physical access to a user's device
  • Vulnerabilities in third-party services we rely on (report those directly to the vendor)

Security Contact

Too Fresh To Waste โ€” Security Team

Tunisia

support@toofreshtowaste.com

For general support requests, please use support@toofreshtowaste.com instead.