Course platform security checklist

• A single canAccessLesson(user, lesson) and canGrade(instructor, submission) pair gates every lesson, file, quiz and grading route; RLS scopes enrollments, progress, attempts and submissions by user and instructors only reach their own courses' rosters. Removing enrollment immediately blocks access, including signed URL issuance.

• Answer keys never leave the server; grading, deadline (started_at + time_limit_sec) and attempt count are enforced server-side on submit; attempt start is idempotent; question order may be randomised per attempt. Cheating deterrence is stated honestly: no proctoring in phase 1.
• Certificate verify codes are 128-bit random and unguessable, verification is rate limited per IP, and issuance only happens in the job after re-checking completion; instructors cannot self-issue certificates for other users.
• Per-instructor course count, upload storage, video minutes and egress; per-user enrollment of free courses per day; per-user discussion posts per minute; all fail closed and are plan attributes.

• Assignment and lesson uploads use presigned direct-to-bucket URLs with MIME + magic-byte checks, size caps and a virus scan before the file becomes visible; files are served with Content-Disposition attachment from a separate path.

• Instructor and learner rich text is sanitised on write and escaped on render; embeds are allow-listed by provider origin; SCORM/third-party packages (phase 2) run in sandboxed iframes on a separate origin.

• Learner records (names, grades, progress, submissions) are education records: stored under RLS, never in logs, shown to other learners only as display name, exportable and erasable on request (certificates keep the issue record pseudonymised). Instructors see only their own course learners.

• When under-13s or school-managed accounts are in scope: collect date of birth at signup, block account creation under the age threshold without verifiable guardian consent (guardian_consents), disable discussion and public profiles by default for minors, and no behavioural advertising or third-party analytics on learner pages.

• FERPA (applies to US schools or school-contracted deployments): When serving schools that receive US federal funding, grades, submissions and progress are education records: schools are the controllers, access is limited to authorised school officials and the learner/guardian, disclosure needs consent or a written agreement, and records must be exportable.
• COPPA (applies to learners under 13): Collecting personal data from children under 13 requires verifiable parental consent, data minimisation, no behavioural advertising and a deletion path; the safest default is to block under-13 signup unless consent is implemented.
• GDPR (including GDPR-K) (applies to EU users): Learner profiles, progress and submissions are personal data: lawful basis, export and erasure, retention limits, a processor agreement with schools or employers, and parental consent age thresholds (13-16 depending on member state).
• Certificates and credential claims (applies to certificates issued): A certificate of completion is not an accredited credential; copy must not imply accreditation, and verification pages must show revoked status.
• Copyright (applies to instructor-uploaded content): Instructors warrant they own or license uploaded material; provide a takedown flow and repeat-infringer policy.

• instructor storage gb: per-plan cap per instructor; uploads refused at 100% of quota.
• video minutes hosted month: per-plan cap on hosted video minutes (phase 2 pipeline); upload refused over the ceiling.
• video egress gb month: per-plan egress cap; signed URL issue refused over the ceiling.
• email sends per user day: hard daily cap per learner and per course; excess dropped and counted, not queued.
• certificate pdfs per user month: cap on regenerations; issuance itself is once per enrollment.
• payout daily ceiling minor: platform-wide daily payout ceiling, run halts and pages the owner at 100%.

Forge64 gives every app its own Postgres database and runs a quality gate that flags unauthenticated writes and secrets in client code before you see the app. It does not replace your own testing, and it holds no third-party security certification today.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

• Sign in as two different users and try to open each other's records by changing the id in the address.
• Submit each form with an empty value, a very long value and a script tag, and check the result.
• Call each write endpoint without signing in and check that it refuses.

What is the biggest security risk in a course platform?

A single canAccessLesson(user, lesson) and canGrade(instructor, submission) pair gates every lesson, file, quiz and grading route; RLS scopes enrollments, progress, attempts and submissions by user and instructors only reach their own courses' rosters. Removing enrollment immediately blocks access, including signed URL issuance.

Does a course platform have compliance obligations?

FERPA, if you have US schools or school-contracted deployments: When serving schools that receive US federal funding, grades, submissions and progress are education records: schools are the controllers, access is limited to authorised school officials and the learner/guardian, disclosure needs consent or a written agreement, and records must be exportable. This is a starting point, not legal advice.

Will Forge64 certify my app as secure?

No. Forge64 holds no third-party security certification today and does not certify apps. The checklist is a way to test your own app.

• How to build a course platform
• Course platform architecture
• Example prompt for a course platform
• Course platform scaling checklist
• Often combined: video streaming app
• Often combined: marketplace
• All app types