Security Overview

Server-side authorization

Teacher and Admin access uses the platform's own sign-in (Google or email and password, with server-side sessions). Every access to instructor and admin features is checked on the server for identity and role, denying by default. Protected pages check permission before they are served, so no page content is sent to an unauthorized visitor.

Server-side scoring

Correct assessment answers exist only on the server and never appear in public pages, site code, static data or downloads. Submitting the same attempt again is never re-scored. The same principle applies to certification: rubrics, eligibility rules and review outcomes for applied-skill certificates and the other certification levels exist only on the server and in protected admin tools, and every issuance or revocation decision is made by the server, never by what the front end shows or hides.

Input and output handling

• All API input is schema-validated
• Database queries always use bound parameters, never string-concatenated user input
• Text entered by users is safely escaped when displayed
• Exported CSVs neutralize spreadsheet formula injection
• Changes made with a signed-in session must come from the same origin, so another website cannot trigger them

Protections for course feedback

• Every feedback endpoint is checked on the server: a learner can read and write only their own feedback; instructors see only their own courses and sessions; an HR viewer sees only the organizations they were granted, and the role does not satisfy any other organization-data check
• Statistics always apply the minimum group size (nothing below 5 responses), and the way sessions and totals are combined also prevents a hidden small group from being recovered by subtraction
• Comments are masked on the server first and then moderated by rule; a learner's original text goes only to its author and to the administrator moderation page, never to HR, instructors or an unmasked export column
• Submitting, event reporting and reminder emails are rate limited or capped per run; form performance uses anonymous counters only, and learners cannot forge the server-side submission counts
• CSV exports neutralize spreadsheet formulas; every HR read and export, comment moderation, and retention dry run or cleanup is written to the audit log (organization, kind and counts only, never comment text)
• The live session-code check only reports whether a code is valid, needs a sign-in and is rate limited; binding a session to a course changes who can manage it, so only admins can change it, the impact is shown first, the session code must be typed when feedback already depends on it, and every change is audited
• Retention cleanup needs an administrator to type DELETE; the schedule only reports and never deletes automatically

Security headers

Every response carries security headers including Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy. Non-public pages are also marked as not to be indexed by search engines. Sensitive actions such as teacher slide exports, role grants and credential setup changes are recorded in an audit log that identifies the actor by account, not by email.

Least privilege and data minimization

Each role gets only the permissions it needs; the platform uses learner codes instead of real identities and collects only the minimum data a course requires. Sign-in, registration, password reset, session joining, name edits, teacher slide downloads and the public partnership-request form are rate-limited, using hashed keys so no raw IP address or email is stored for this purpose, and public forms can be protected with Turnstile verification.