Security

Security, Privacy and Compliance

A practical guide for running LabSchool Exams responsibly in schools, training organizations, and public or private educational activities.

Purpose of this guide

This page explains the main security and privacy mechanisms of LabSchool Exams in plain language. It helps administrators and educators understand what the application does, what must be configured, and what should be checked before real use.

This page is not legal advice. Each organization remains responsible for its own data-protection policy, consent process, retention rules, and local legal obligations.

A. Application security controls

The application includes controls that reduce common risks in school-oriented and public quiz workflows.

  • Security headers are applied to application responses, including X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, and cross-origin hardening headers.
  • Content Security Policy is enabled by default. It limits where scripts, styles, frames, fonts, images, and connections may load from.
  • Runtime quiz pages are marked with no-store cache headers so question and answer content is not kept in browser history caches.
  • Sensitive flows use throttling, including registration, feedback, quiz PIN validation, and student code validation.
  • Public quiz links, student links, display-session links, and selected PDF links use signed URLs where applicable.
  • Teacher and administrator back-office routes require authentication and verified email. Administrative actions are separated by permissions.

B. Privacy-aware participation

LabSchool Exams is designed so participants do not need to create user accounts just to take a quiz. The quiz creator chooses the participation model that fits the activity.

  • Participants may join with a temporary quiz PIN or student code.
  • Participants may receive personalized signed links when the process requires controlled individual access.
  • Guest or anonymous flows can be used where named participation is not necessary.
  • Participant-name search support uses blind-index style hashing so search can work without relying only on plain text matching.
  • Certificates and attempt PDFs are protected by eligibility checks and signed or controlled access routes where applicable.

C. Data retention and scheduled cleanup

Security is not only about login screens. In an educational platform, old personal data should not remain forever without reason.

  • Old quiz attempt personal data can be anonymized by the scheduled privacy:prune-exam-personal-data command.
  • Stale student registry rows can be pruned when they are no longer linked to recent or active attempts.
  • Temporary second-screen display sessions and anonymous pool reservations are pruned by runtime:prune-temporary-state.
  • Timed quiz attempts are finalized by quiz-attempts:expire.
php artisan schedule:list
php artisan privacy:prune-exam-personal-data
php artisan runtime:prune-temporary-state

For production, the Laravel scheduler must run every minute. If it stops, attempt expiry and privacy cleanup may drift from the intended policy.

D. What the operator must configure

The application provides safeguards, but the organization running it must configure the deployment correctly.

  • Use HTTPS in production. HSTS is sent when the request is already served securely.
  • Keep APP_ENV=production and APP_DEBUG=false on a public server.
  • Set APP_SOURCE_URL to the canonical repository or release source, especially because the project is AGPL-licensed.
  • Configure mail correctly if registration, feedback, quota requests, or notifications are used.
  • Run the queue worker when mail or other queued tasks use the database queue.
  • Review SECURITY_REGISTRATION_ALLOWED_EMAIL_DOMAINS when teacher registration should be limited to specific domains such as sch.gr.
  • Configure Cloudflare Turnstile keys if bot protection is required for registration.

E. Useful security settings

These environment values are the main knobs an administrator may need to review.

APP_ENV=production
APP_DEBUG=false
APP_URL=https://your-domain.example
APP_SOURCE_URL=https://github.com/LabSchool-GR/Exams
SESSION_SECURE_COOKIE=true

SECURITY_REGISTRATION_ALLOWED_EMAIL_DOMAINS=sch.gr
SECURITY_REGISTRATION_THROTTLE=5,1
SECURITY_FEEDBACK_THROTTLE=3,10
SECURITY_QUIZ_CODE_THROTTLE=10,1
SECURITY_STUDENT_CODE_THROTTLE=5,1

SECURITY_CSP_ENABLED=true
SECURITY_CSP_REPORT_ONLY=false
SECURITY_CSP_REPORT_URI=

SECURITY_ANONYMIZE_ATTEMPTS_AFTER_DAYS=180
SECURITY_PRUNE_STUDENTS_AFTER_DAYS=180
SECURITY_PRUNE_DISPLAY_SESSIONS_AFTER_HOURS=48

F. Public information pages

The application includes public pages that explain the service, terms, and privacy notice. These should be reviewed and adapted by each deployment where needed.

  • /about
  • /terms
  • /privacy

The footer also exposes license and source-code references. If a modified version is offered over a network, the AGPL license requires the corresponding source code to be available under the same license terms.

G. Checklist before real use or release

  1. Open an authenticated page and a public quiz page and confirm that security headers are present.
  2. Confirm CSP is enforced, especially after template or JavaScript changes.
  3. Confirm guest and public routes do not show teacher-only controls.
  4. Test public quiz links, student links, signed PDF links, certificates, and verification flows.
  5. Confirm the scheduler and queue worker are running.
  6. Confirm mail delivery or log-mail behavior.
  7. Test PDF and Excel exports after framework, dependency, or template upgrades.
  8. Review /about, /terms, and /privacy before public deployment.