Aegis Aegis Security

SECURITY. Production Readiness

Protect the platform around the features.

This root site reduces accidental exposure, but production safety still depends on the hosting stack, configured secrets, database access, and every Aegis module being reviewed before launch.

Secrets and credentials

Before production, move database passwords, Discord tokens, webhook URLs, captcha keys, and mail credentials out of source-controlled files.

  • Use environment variables or server-level secret storage where your host supports it.
  • Never expose bot source, SQL schemas, project files, or credential examples publicly.
  • Rotate any token that was ever committed, shared, or placed in a public web directory.

Web server hardening

The root .htaccess blocks obvious sensitive files and direct source folders on Apache.

  • Keep Options -Indexes enabled so directory listings stay off.
  • Use router.php through the included PHP dev-server task so local testing mirrors the same deny posture.
  • Use HTTPS, secure cookies, and a production PHP configuration.
  • If you deploy on Nginx or IIS, mirror the same deny rules outside .htaccess.

Module safety

The portal uses a fixed route registry instead of accepting arbitrary redirect targets.

  • Add new modules through config/modules.php.
  • Add release lanes through config/releases.php instead of linking raw project folders.
  • Treat the worker sync key used by api/bots.php like a production secret; rotate it after any leak or environment move.
  • Prefer native bot workers pulling from the website control plane instead of trying to spawn background services from PHP.
  • Use Aegis Core identity links instead of copying passwords between Auth and Restore.
  • Let the Restore-to-Auth bridge provision missing Auth accounts only after a verified Restore login; never overwrite an existing Auth password automatically.
  • Keep Auth and Restore paths stable until their internal redirects are modernized.
  • Keep Auth and Restore session cookies isolated by name so one dashboard cannot overwrite another.
  • Require CSRF tokens on login, registration, and reset forms before expanding protection to every dashboard POST.
  • Throttle login, registration, and reset attempts so brute-force traffic is slowed before production.
  • Run health.php after moving folders or changing deployment paths.

NOTE. Preserved Modules

Preserved does not mean audited.

Auth and Restore were intentionally kept working in-place. Before public deployment, the next pass should review SQL usage, session flags, CSRF handling, OAuth redirect settings, bot token storage, and dependency versions.

Recommended first checks health.php Auth/includes/credentials.example.php Restore/website source/includes/connection.php Restore bot source resources file