View Categories

Security Checklist

4 min read

Table of Contents

This checklist lists the operational measures Academy & Exam OS supports and what you should configure before going live. It makes no certification claim.

Transport #

  • Serve the site over HTTPS only. The installer refuses plain HTTP on a public host, and production sessions use secure cookies.
  • If TLS ends at a proxy or load balancer, it must set X-Forwarded-Proto: https.

Security headers #

The application sends these headers on its pages:

  • Content-Security-Policy — a strict policy with a per-request nonce for scripts, object-src 'none', base-uri 'self', form-action 'self' and frame-ancestors 'self'. It is the main browser-side protection against injected scripts and clickjacking.
  • X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and Permissions-Policy: camera=(), microphone=(), geolocation=().

Important: Hosting providers, CDNs and “force HTTPS” features must not replace these headers. Some shared-hosting CDNs add their own Content-Security-Policy (for example only upgrade-insecure-requests) and thereby remove the application’s policy. Check the headers a visitor receives (browser developer tools → Network → the page → Response headers) and switch off any panel or CDN option that overrides Content-Security-Policy.

Document root and file permissions #

  • Use Web/webroot/ as the document root and nothing above it. Where the parent folder must be served, keep the shipped .htaccess files in Web/, Web/config/, Web/storage/, Web/tmp/ and Web/logs/; they block direct access.
  • A subdomain folder inside the main domain’s public_html is also reachable through the main domain. The application refuses page requests for other host names, but its static files stay reachable; place the site folder outside another site’s web root where your panel allows it.
  • Web/config/app_local.php holds the security salt and the database password: make it readable only by the web server and cron user (0640 or 0600). The installer writes it as 0600 where the platform supports it.
  • Web/storage/ holds uploaded media, the encryption key and per-installation secrets: writable by the web server, never readable by other accounts on the host.
  • Keep the application files (src/, templates/, vendor/, webroot/) read-only for the web server user where your hosting allows it, except webroot/images/, which receives the website images you upload (logo, homepage slides, blog images).

Database #

  • Use a dedicated database and a dedicated user with exactly SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP, TRIGGER, REFERENCES on that database. No global privileges.
  • Connect over a local socket or a private network. Do not expose MySQL or MariaDB to the internet.

Accounts and sessions #

  • You create the owner account during installation with a 12–128 character password. A clean (Mode A) installation has no default or demo accounts.
  • Sign-in attempts are rate-limited per account and per address; password reset links expire after 30 minutes.
  • Staff roles (owner, admin, teacher, student) carry permission sets. Review them under People & Permissions before giving staff access. See Users, Roles, Batches & Access.
  • If you installed with demo data (Mode B), remove it before going live. See Demo Data (Mode B).

Stored credentials #

SMTP passwords, AI provider keys, Google client secrets and payment provider secrets are stored encrypted with the installation’s own key (Web/storage/keys/integration.key) and are never displayed again after saving. Back the key up together with the database.

Uploads #

Uploads are limited by type and size (images, PDFs up to 20 MB, videos up to 250 MB). Private files (PDFs, videos, question images) are stored outside the document root under Web/storage/private/, and served only through short-lived, access-checked links — never by a direct path. Images you upload for the public website (logo, homepage slides, blog images) are public by nature: a copy is placed in Web/webroot/images/ (user-* files) and served directly.

Scheduled tasks #

Run the cron jobs under the web server user or a user in the same group — never as root. See Cron Jobs & Background Worker.

Backups and updates #

Keep backups outside the website folder, and take one before every update. See Backups & Restore and Updating Academy & Exam OS.

Reporting a security issue #

Report suspected vulnerabilities to OsDot Solutions through the support channel rather than a public forum. Include the product version from VERSION and the steps to reproduce.

Related documents #

Watch the Video Tutorial #

This topic is also covered in Academy & Exam OS Video Tutorial 12: Updates, Backups, Security & Support (watch on YouTube). All Academy & Exam OS video tutorials.

What are your Feelings