Security

1. Connections

• Every page and request uses HTTPS. Browsers are told to use HTTPS for a year (HSTS).
• The site cannot be shown inside another site's frame.

2. No Cookies and No Outside Code

• The site sets no cookies at all.
• Every script, style, font and image comes from the course itself. Nothing loads from advertising, analytics or other outside services.
• A Content Security Policy enforces this: browsers refuse scripts from anywhere else, refuse inline scripts and, where supported, refuse code that writes raw HTML into the page.

3. Your Account

• There is no learner password to steal or reuse. Your browser creates a signing key for this site and keeps it so that page code can use it and nothing can read it out.
• Every request about your account is signed with that key and carries a one-time number and the time, so a captured request cannot be replayed.
• Organisation sign-in uses OIDC (with PKCE, a single-use random state and a nonce) or SAML 2.0 (with signed assertions and replay checks). Sign-in can only finish in the browser that started it. Callback addresses are fixed, and we ask the organisation for your identity, email and name only.

4. Your Data

• Your name, email address and organisation are sealed in your browser before they are sent (ECDH P-256 key agreement, AES-256-GCM), on top of HTTPS, and stored encrypted on the server.
• We find accounts by keyed fingerprints of email addresses, so a copy of the database alone does not reveal them.
• Records are kept in a server folder the web cannot reach.

5. Protection From Abuse

• Rules check every request for common attack patterns (for example SQL injection, script injection and path traversal) and block them.
• Sign-in and enrolment routes are rate-limited. An address that goes over the limit, repeatedly sends attacks or probes for common weaknesses is blocked automatically.
• Automated tools are refused on enrolment, sign-in, account and administration routes.

6. Errors

• If something fails, you see a short message and a reference number. Error messages never show file names, database details, software versions or other internal detail.
• The full record goes to a private, searchable log with alerts, kept for 90 days.

7. Administration

• One course administrator. The password is stored only as a bcrypt hash; sign-in is rate-limited and blocked after repeated failures.
• Administration sessions are bound to a key in the administrator's browser, end after 30 minutes idle or 8 hours, and every action is recorded.

8. Deletion

• Delete My Account deactivates your account at once and erases it, including from our fault records, within 24 hours. We email you a report of what we held and a confirmation when nothing is left.

9. What We Cannot Do

• Data in your browser is only as safe as your device. Lock your device and keep your browser up to date.
• Websites cannot pin their own certificates in browsers. We use HSTS, a DNS record that limits which certificate authorities may issue certificates for the site, and certificate transparency monitoring instead.

10. Reporting a Security Problem

Please email info@scalentric.org with "Security" in the subject, describing what you found and how to reproduce it. Do not access other people's data, and give us reasonable time to fix the problem before telling others. Our security.txt file has the same details. If we learn of a breach that puts your data at risk, we follow our incident response plan, notify the Nigeria Data Protection Commission where the law requires within 72 hours, and tell affected learners without delay.