Security

What's actually built, not a marketing checklist

Honesty notice: every control listed below is genuinely implemented in AcNexa today, not a roadmap item written as if it were done. AcNexa has not yet undergone a formal third-party security audit or penetration test — that's a planned next step, not something we claim has already happened.

Tenant isolation

Every school's data is scoped by school at the database query level itself, not just hidden behind a login screen or filtered in the application UI. This is enforced on every single database read and write, automatically, without each feature having to remember to add its own filter. As a second, independent layer, row-level security is also enabled directly in Postgres on every table, denying access by default to any database role that isn't the application's own — defense in depth, not a single point of failure.

Account security

Passwords are hashed with bcrypt - never stored or logged in plain text, anywhere.
Two-factor authentication (TOTP) is available for staff accounts, with recovery codes.
Login attempts are rate-limited: repeated failed attempts against one account lock it out for a period, closing off credential-guessing without needing a human to intervene.
A suspended or deactivated account loses access within a minute, not just on its next login.

Data in transit and at rest

Every connection to AcNexa is HTTPS-only, with HTTP Strict Transport Security enabled so a browser never even attempts an insecure connection after the first visit. Sensitive credentials a school stores with us (payment and SMS provider keys) are encrypted at rest, not kept as plain text in the database. Staff and pupil documents are stored privately and served through short-lived signed links, not permanent public URLs.

Application hardening

A Content Security Policy, HSTS, and standard security headers (X-Frame-Options, X-Content-Type-Options, Referrer-Policy) are set on every response in production. User- generated content (like student blog posts) is sanitized before it's ever rendered to another visitor, closing the door on stored script injection. Dependencies are scanned automatically and kept up to date.

Accountability

Sensitive platform-level actions - creating a school, changing billing, resetting a user's two-factor authentication, an AcNexa staff member viewing a school's account for support - are written to an audit log before they take effect, so there is always a record of who did what and when.

Reporting a security issue

If you believe you've found a genuine security vulnerability in AcNexa, please report it privately to acnexa0@gmail.com or +233 53 653 0310 rather than a public issue or social media post, and give us a reasonable chance to fix it before disclosing it publicly. We'll acknowledge a genuine report and keep you updated as it's addressed. See also /.well-known/security.txt.