Identity and access control
Every account is verified through token-based identity checks before a session is trusted. Identity verification alone does not grant access — every request is checked against FTA's own authoritative account record.
Security
How FTA protects accounts, data, and published records.
FTA is built in layers — access control at the account level, authorization at the server level, and integrity checks on the evidence itself. This page explains that approach in plain language.
No platform can guarantee it is immune to every attack, and FTA does not claim to be. This page describes the controls FTA has in place today. It is not a claim of external certification — reference any independent audit or certification only where FTA has actually obtained one.
Access and account security
Controls that govern who can sign in and what they can do once they have.
Backend authorization
Protected actions are enforced on the server, not the browser. Requests are authorized before any protected data is read or written, independent of what a client application claims about the user.
Role-based access control
Accounts are assigned roles (such as diner, restaurant owner, or administrator), and each role is limited to the actions appropriate for it. Owner accounts cannot self-assign elevated privileges.
Active-user enforcement
Access depends on current account status, not just identity. Disabled, suspended, or restricted accounts are blocked from taking protected actions, even with a valid sign-in.
Abuse and rate-limit protections
Automated request throttling and abuse-pattern detection apply across public and authenticated endpoints, with escalating restrictions for accounts or sources that show abusive behaviour.
Audit logging
Administrative and other sensitive actions are recorded in an internal audit trail, including what changed and when, to support accountability and after-the-fact review.
Evidence integrity
Published records are structured to be checked, not just trusted.
Beyond account-level access control, FTA applies a separate layer of integrity protection to the transparency records themselves.
Evidence integrity layer
Published transparency records are organized using hash-linked evidence structures, so that a later record can be checked against the state that came before it, rather than standing alone.
Merkle-tree verification concept
FTA uses Merkle-tree-style structures to summarize batches of records into a single verifiable value. This makes it possible to check that a specific record is genuinely part of a published set, without exposing unrelated data.
Signed transparency records
Published transparency checkpoints are cryptographically signed. Anyone can use FTA's public verification tools to check that a checkpoint has not been silently altered after publication.
Testing and validation posture
Access control, evidence-integrity, and verification logic are covered by an automated test suite that runs as part of FTA's development process, alongside manual review of changes to sensitive areas of the platform.
Responsible disclosure
If you believe you have found a security issue affecting FTA, please report it privately to fta-team@foodtransparencyapp.com rather than disclosing it publicly. A dedicated disclosure policy and reporting channel is being formalized as the platform moves beyond pilot stage.
FTA is not a government authority, regulator, or certification body. This page describes platform security controls, not the safety practices of any individual restaurant. Restaurant safety indicators shown elsewhere on FTA reflect available public and restaurant-submitted records, not a security or safety guarantee.