Security at AajAI

This page explains the security controls built into AajAI.

Account and administrator protection

Learner passwords are stored as secure password hashes, sessions are server-side, login/session identifiers are rotated at important privilege changes, and rate limits reduce brute-force abuse. Administrator access requires TOTP two-factor authentication and supports recovery codes. Sensitive configuration values are encrypted at rest where the application marks them as secrets.

Application controls

Forms use CSRF protection, database writes use prepared statements, output is escaped by default, upload areas are restricted, private application directories are blocked from direct browsing, and private pages use no-store caching. Public responses use a separate cache profile so search engines and browsers do not treat every marketing page as private.

Security headers

Pages carry a Content-Security-Policy, X-Content-Type-Options, frame protection, Referrer-Policy and Permissions-Policy. The whole site is served over HTTPS.

Payments

Razorpay processes payment instruments. AajAI does not store full card numbers or UPI PINs. Course entitlements are not granted merely because browser JavaScript says a payment succeeded: the server verifies the callback and reconciles the signed webhook with amount/currency and idempotency checks.

AI Coach and learner results

The Coach endpoint and credentials are never exposed to the browser. Attempts have length and rate limits, and a rubric scores attempts if the AI model is unavailable. Result Locker access is checked by user ownership so one learner cannot fetch another learner's result simply by changing an ID.

Backups and audit trail

The application contains pure-PHP database backup support suitable for shared hosting, documented restore testing, security events and an administrator audit log. Backups can be test-restored before they are relied on.

Report a vulnerability

Use the security contact in /.well-known/security.txt. Do not include passwords, payment credentials or unnecessary personal data in a report. Good-faith reports should describe the affected URL, the steps to reproduce and the security impact.