This document describes how security is handled in the Hoterstellar backend (abushayedgit/hoterstellar_sr) and how to report a vulnerability.

This is a private, closed-source commercial project. This policy is written for the small group of people with repository access (owner, contributor, and anyone the owner grants access to) — it is not an open-source public-disclosure program.

There is no version-branch matrix for this project — it is deployed continuously from a single production line.

Only the code currently running in production (main) and the environment variables configured on the two live Render services (hoterstellar-api, hoterstellar-worker) are in scope for security concerns.

Do not open a public GitHub issue for a security vulnerability. Issues are visible to anyone with repository access and are not an appropriate channel for reporting exploitable weaknesses before they're fixed.

Instead:

1. Contact the repository owner, @abushayedgit, directly (or the contributor @heyAbdullahBruh) via a private channel — direct message, email, or another agreed-upon secure channel.
2. Include:
   • A clear description of the vulnerability and its potential impact.
   • Steps to reproduce it (a minimal request/payload is ideal).
   • The affected endpoint, module, or file, if known (e.g. POST /api/v1/auth/user/signin, src/middlewares/auth.base.middleware.js).
   • Whether you believe it's already being exploited.
3. Do not test the vulnerability against production data beyond what's strictly necessary to demonstrate it. Do not access, modify, or delete another user's or admin's data.

Response expectations: as a small, closed team, there is no formal SLA. Treat anything that looks like an authentication bypass, privilege escalation (e.g. a manager/admin account reaching super_admin-only actions), or data exposure across users as urgent and flag it as such when reporting.

These are not new reports — they are documented gaps already tracked in README.md (see Implementation Notes / Inconsistencies and System Limitations). Please don't re-report them; link back to those sections if you want to discuss fixing one:

• Admin password reset (POST /auth/admin/reset-password) is unimplemented and always fails — the reset token generated by request-reset-password is never persisted.
• src/middlewares/auth.base.middleware.js's verifyAccessToken calls require("jsonwebtoken") inside an ESM module, which is not valid Node.js ESM syntax.
• src/app/bootstrap.js references functions (createApp, connectDatabase) that don't exist in the files it imports from, and is not used by the running server.js.
• CSRF middleware (setCsrfCookie, csrfProtection) is registered in src/app/app.js after the API routes, 404 handler, and error handler — the effective enforcement order should be verified before relying on it.
• No automated test suite exists, so regressions in any of the above (or in auth/authorization logic generally) are not currently caught by CI.

For context when assessing a report's severity, here is what's actually implemented today (see README.md → Security Architecture for full detail):

None of this is described as "unhackable" or "enterprise-grade" — it's a description of what exists, and a report that finds a gap in or around any of the above is exactly the kind of report this policy wants.

• Never commit .env, real API keys, database URIs, or JWT secrets to this repository. Only .env.example (with placeholder values) belongs in version control.
• If a secret is ever accidentally committed (even in a since-reverted commit — it's still in git history), treat it as compromised: rotate it immediately in Render's environment variable settings and in the upstream provider (MongoDB Atlas, Upstash, Brevo, ImageKit, Google reCAPTCHA), not just in .env.
• ADMIN_JWT_SECRET and USER_JWT_SECRET must each be at least 32 characters (enforced by src/config/env.js) and should be generated independently, not derived from each other.

Dependabot is configured (.github/dependabot.yml) to open weekly PRs for both npm packages and GitHub Actions. Security-relevant updates (flagged high severity or above by npm audit / GitHub's Dependency Review) should be prioritized ahead of routine dependency bumps.