Skip to main content
Trust

Security practices

What we actually do to keep your account, your journal and your messages safe.

Last updated 30 July 2026

Scope and honesty

This page is maintained by the Anti-Diet Club team to answer common security and privacy questions. It describes controls that are enabled today. It is not a certification, an audit report or an independent verification, and it does not claim compliance with any standard. Where we reference frameworks such as the OWASP Top 10 or the NIS2 style organisational measures, we mean that they guide our engineering choices.

Access control

  • Authentication is handled by a managed identity provider with email and password or Google sign in. Passwords are never stored by us in readable form.
  • Every data table enforces row level access rules, so a member can only read and write their own journal, check ins and messages.
  • Roles (member, premium, professional, admin, owner) live in a dedicated table and are checked server side. Roles can never be granted from the browser.
  • Privileged database helper functions are not executable by anonymous visitors.
  • Uploaded journal photos are stored in a private bucket and served only through short lived signed links.

Application hardening

  • All traffic is served over HTTPS with strict transport security.
  • Security response headers are set on every request: content type sniffing disabled, restrictive referrer policy, restrictive permissions policy, cross origin isolation defaults and a content security policy.
  • Server side input validation with strict schemas and length limits on every endpoint that accepts user input, in addition to client side checks.
  • Rate limiting on the AI endpoint to limit abuse and cost based denial of service.
  • Secrets are held in the server environment only and are never exposed to the browser bundle.
  • Dependencies are kept current and reviewed for known vulnerabilities.

How we think about threats

We review changes against the OWASP Top 10 categories that matter for this app: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, data integrity, logging gaps and server side request forgery. We also reason about realistic adversary behaviour in the style of MITRE ATT&CK: credential access on member accounts, privilege escalation towards admin roles, and data collection or exfiltration of private journals. The controls above map directly to those paths.

Operations and incidents

  • Errors and security relevant events are logged server side and reviewed. Logs do not contain journal content or credentials.
  • Backups of the managed database are handled by our infrastructure provider.
  • If we detect an incident, we contain it, assess the impact on personal data, and notify the supervisory authority within 72 hours where the GDPR requires it, plus affected members when the risk is high.

Report a vulnerability

If you believe you have found a security issue, email antidietclub2304@gmail.com with the details and how to reproduce it. Please do not access or modify other people's data, and give us reasonable time to fix the issue before disclosing it. We will acknowledge your report and keep you informed.

Shared responsibility

  • Our infrastructure providers secure the hosting platform, the managed database and the identity service.
  • We secure the application, its access rules, its configuration and how member data is handled.
  • You help by using a strong unique password, keeping your device safe and reporting anything suspicious.

See also our privacy policy and cookie policy.

SOS, gratuit