1. Organisation isolation
- Business data is attached to an organisation identifier (
tenant_id). - Sensitive routes derive the effective organisation from the authenticated session and apply that scope to reads and changes.
- Roles and permissions are checked server-side. Browser-supplied values cannot grant additional rights.
- Demo status is resolved server-side and kept separate from customer organisations.
2. Authentication and sessions
- Passwords are derived with PBKDF2-SHA-512, an individual random salt and 210,000 iterations.
- The password policy requires at least 12 characters, including lowercase, uppercase, number and special character.
- Failed logins are counted and may temporarily lock the account.
- Session tokens are random and only their SHA-256 digest is stored.
- Production session cookies use HttpOnly, Secure and SameSite=Lax. Active sessions per user are limited.
- Password-reset tokens are temporary, hashed and single-use.
3. Access control
- Administrator, HR, Recruitment, Manager, Employee, SuperAdmin and Demo profiles have distinct scopes.
- Sensitive operations check the authenticated role, authorised scope and organisation.
- Role changes, administrative access and denied actions are recorded by the audit mechanisms.
4. Web and API protection
- Public services are exposed through HTTPS and the application enables HSTS in production.
- A Content Security Policy restricts sources, blocks framing and disallows embedded objects.
- Security headers reduce MIME confusion, framing, referrer leakage and unnecessary device permissions.
- Write requests require an allowed origin and CORS uses an allow-list.
- Rate limits protect authentication and public forms from automated abuse.
- Production errors return a generic message and an incident identifier without exposing the technical stack.
5. Logging and supervision
The Control Plane consolidates recent authentication success and failures, account locks, unusual network origins, role changes, sensitive API calls, critical server errors and authorised or denied Demo access. Alerts are prioritised. Passwords, tokens, cookies and authorisation values are masked in audit details; e-mail and IP fingerprints shown by the security centre are hashed.
6. Backup, restore and rollback
- The versioned MySQL procedure creates consistent dumps, encrypts archives with Age and transfers them to OVH object storage.
- SHA-256 sums and size checks verify transferred archives.
- A verification procedure decrypts a backup in temporary storage and validates checksums and dumps without replacing the active database.
- Application releases are versioned; health and readiness checks trigger an automatic rollback when a target release fails.
7. Demo environments
- Access to the free-use Demo platform requires server-validated authorisation.
- Expired, revoked, reused or forged codes are denied and logged.
- Demo organisations are identified separately and cleanup is provided at the end of the journey.
- The interactive presentation alone grants no access to a customer organisation.
8. Data export and customer departure
- Exports and departure operations are subject to role and organisation checks.
- CSV exports neutralise values that spreadsheet software could interpret as formulas.
- Sensitive operations are auditable and do not trust a freely supplied browser tenant identifier.
9. Software delivery
- Changes use Git, pull-request review and CI checks before integration.
- Schema migrations are versioned and separated from the application runtime account.
- Operational secrets are supplied through protected environment configuration and must not be committed.
- Releases are tied to a commit and retained for controlled rollback.
10. Shared responsibilities and limits
Customer organisations and users must manage accounts and roles carefully, remove obsolete access promptly, keep credentials confidential and report unusual behaviour.
Yloria claims no ISO certification, security qualification or invulnerability on this page. Audits, tests and controls reduce risk but cannot eliminate it entirely.
11. Report an incident or vulnerability
Report suspicious access or a vulnerability to support@yloria.fr. Do not send passwords, tokens or complete personal data. Include only the time, affected page, action performed and any displayed incident identifier.