Security
How the platform protects the data in it, and how to report a problem.
Ultimo aggiornamento: 2026-08-23
Questo documento è redatto in inglese, olandese e francese. Stai leggendo la versione inglese.
Separation between companies
Every table in the database enforces row-level security. Which rows a request may read or write is decided by the database from the identity of the person making it — not by the screens, and not by the application code that could be bypassed.
That separation is not taken on trust. A dedicated job runs on every change, against a database built from scratch, and asks who may touch which row; it currently makes 208 such assertions, and a change that breaks isolation does not reach production.
Credentials and links
Passwords are handled by Supabase Auth and are never seen by the application.
Links that act as credentials — a company invitation, a personal calendar subscription — are 32 random bytes, and only their SHA-256 digest is stored. A copy of the database is therefore a list of spent guesses rather than a set of working links. A wrong link and a revoked one are indistinguishable from outside, so guessing reveals nothing.
A calendar subscription is read-only, carries no instructions or notes, can be revoked at any moment, and records when it was last read — which is the only thing that makes a link that leaked visible to the person it belongs to.
What is not collected
Worker coordinates are not stored. A clock-in checks whether it happened at the work location and keeps only that answer and a distance rounded to ten metres. The columns that once held positions were deleted; data that is not held cannot leak.
Logs and errors
Logs carry an event name, a code and identifiers, from a fixed list of permitted fields. Free-form content does not travel: no message from the database, no row contents, no token. This is enforced in the code rather than left to habit, because a provider's error message quotes back the value that caused it — and that value is whatever somebody typed.
Reporting a vulnerability
Write to contact@belnexenergy.be with enough detail to reproduce the problem. Reports are read by a person and answered.
Testing against your own account and your own company's data is welcome. Testing that reaches another customer's data, degrades the service for others, or involves social engineering is not, and is not covered by the invitation above.
BELNEX Energy · contact@belnexenergy.be