Security & Authentication Architecture

Overview

SafeExam Platform is built with a security-first architecture. Exam delivery, authentication, and integrity signals are enforced on the server — the browser UI reflects rules but cannot bypass them.

This document summarizes our public security model for examination controllers, IT reviewers, and educators. For vulnerability reports, email [email protected] with subject Security.

Core principles

• •Sessions stored in httpOnly, Secure, SameSite=strict cookies — not localStorage
• •Role-based access control (RBAC) on every protected API route
• •CSRF tokens required for state-changing requests when using cookie auth
• •Exam integrity events tied to session_id for auditable logs
• •Rate limiting on sensitive authentication endpoints
• •Security headers (HSTS, frame denial, MIME sniffing protection) on marketing and app routes

Student authentication

Students sign in with Google OAuth 2.0. The backend verifies the ID token signature, expiration, and email before creating or loading the user record and issuing a session cookie.

Students access exam participation flows only — not educator dashboards, exam authoring, or administrative APIs.

Student login flow (simplified)

Student → Google OAuth
       → Backend verifies token with Google
       → User record created or loaded
       → httpOnly session cookie set
       → Student dashboard / exam join

Educator & developer authentication

Educators and approved developers use email and password login separate from student Google OAuth. Passwords are stored hashed (bcrypt). Educator access can be gated by institutional approval workflows.

Developer portal routes are noindex and disallowed in robots.txt — they are not part of the public marketing surface.

Session management

• •JWT-based session tokens carried in httpOnly cookies
• •Invalid or expired sessions are cleared server-side
• •Protected app routes (/educator, /student, /exam) are noindex for search engines
• •Middleware enforces role-appropriate route access before page render

Authorization (RBAC)

• •Student — join exams, submit answers, view released results
• •Educator — create exams, monitor sessions, export results within their scope
• •Developer — internal operations portal (not publicly indexed)
• •Every API validates role and resource ownership before returning exam or student data

CSRF protection

Because authentication uses cookies, SafeExam Platform implements CSRF protection on POST, PUT, and DELETE requests. The frontend includes a CSRF token in a custom header; the backend rejects requests without a valid token.

This mitigates cross-site request forgery when browsers automatically attach session cookies.

Exam integrity & monitoring

• •Tab switch, blur, and fullscreen events logged per exam session
• •Violation counts enforced server-side (e.g. auto-submit after configured tab-switch threshold)
• •Optional deterrent camera shows a local browser preview — not uploaded by default
• •Activity snapshots and session events available to educators in Live Control
• •Integrity signals support educator review — they do not alone prove misconduct

Coding assessment isolation

• •Student code runs in sandboxed execution environments (Judge0 integration in production)
• •Hidden test cases evaluated server-side on final submission
• •Coding API endpoints scoped to active exam sessions

Data handling

Exam answers, session events, and integrity logs are stored in our application database and tied to session and exam identifiers. See our Privacy Policy for retention, AI question generation (QIE), and institutional deployment options.

Institutions requiring private hosting or custom data boundaries can contact us for dedicated deployment discussions.