Trust starts in the architecture.

1. Our approach

Security is treated as an architectural constraint, not a layer added at the end of a project. The structural decisions — authorisation model, data isolation, where secrets live, traceability — are taken at design time.

This page describes engineering practices. FraXus claims no certification (ISO 27001, SOC 2 or otherwise) and therefore displays none.

2. Authentication and access control

• Authentication through signed sessions or short-lived tokens.
• Role-based access control (RBAC), enforced server-side.
• Least privilege: every role, service and key holds only the rights it strictly needs.
• Strict separation of development, test and production environments.
• Account lifecycle procedures: invitation, revocation, recovery.

3. Multi-tenant architecture

The SaaS products we build isolate data per organisation. Every request is filtered by the tenant scope of the authenticated user, and configurations, integrations and credentials are attached to the tenant.

4. Secrets and OAuth token management

No secret is exposed to the browser. API keys, OAuth client secrets and service credentials stay server-side, in a secrets store managed by the execution platform, and are never committed to source control.

For third-party integrations performed on behalf of a customer:

• access and refresh tokens belonging to a customer are held in encrypted application storage, attached to the relevant tenant — never in one environment variable per customer;
• requested scopes are limited to what the integration actually needs;
• token revocation and rotation are supported;
• disconnecting an integration deletes the associated tokens.

5. Encryption

• Encrypted transport (TLS) on all public traffic.
• HSTS and strict security headers on the site’s responses.
• Encryption at rest provided by the managed database and storage services in use.
• Additional application-level encryption for sensitive third-party credentials.

6. Security of this site

• A restrictive Content Security Policy, with no third-party script executed by default.
• X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy applied to every response.
• Forms validated server-side, with rate limiting and anti-spam protection.
• No form data is stored in the browser.

7. Logging and auditability

Sensitive events — authentication, permission changes, connecting and disconnecting integrations, administrative actions — are logged so they can be traced. By design, logs avoid containing secrets or unnecessary personal data.

8. Backups and continuity

The production systems we operate have regular backups and documented restore procedures, along with application monitoring and alerting on anomalies.

9. Development and dependencies

• Code review before production.
• Reproducible deployments through a continuous integration pipeline.
• Dependency tracking and updates, with known vulnerabilities remediated.
• A rollback strategy in case of regression.

10. Reporting a vulnerability

If you believe you have found a vulnerability on this site or in one of our products, write to info@fraxus.be with the technical detail needed to reproduce it.

We ask that you do not exploit the flaw beyond what is necessary to demonstrate it, that you do not access or modify data that is not yours, and that you allow us a reasonable period to fix it before any public disclosure. We acknowledge reports and keep the reporter informed of progress.

11. Personal data

The processing of personal data, retention periods and how to exercise your rights are described in our privacy policy.