1. Supported Versions
2. Reporting a Vulnerability
3. Security Best Practices
4. Environment Variables and Secrets
5. Dependency Security
6. Known Security Considerations
7. Disclosure Policy

Only the latest version of AstroDex on the main branch is actively maintained and receives security updates.

If you are running a forked or older version, we strongly recommend syncing with main regularly.

We take security seriously. If you discover a vulnerability in AstroDex, please do not open a public GitHub issue. Public disclosure before a fix is available puts all users at risk.

1. Open a GitHub Security Advisory This is the preferred and most secure channel. It keeps the report private between you and the maintainers until a fix is ready.

2. Alternatively, contact the maintainer directly via GitHub: @SourabhX16

Please provide as much detail as possible so we can reproduce and address the issue quickly:

• A clear description of the vulnerability
• The component, file, or endpoint affected
• Step-by-step instructions to reproduce the issue
• Proof of concept code or screenshots (if applicable)
• The potential impact or attack scenario
• Any suggested fix or mitigation (optional but appreciated)

We will keep you informed at every step. If you do not receive an acknowledgement within 48 hours, please follow up via GitHub.

Follow these practices whenever you contribute code to AstroDex:

• Validate and sanitize all user input before processing or rendering
• Use environment variables for all credentials and configuration secrets
• Keep dependencies up to date and audit them regularly with npm audit
• Use TypeScript's strict mode to catch type-related vulnerabilities at compile time
• Follow the principle of least privilege — request only the permissions your code actually needs
• Use HTTPS for all external API requests
• Prefer well-maintained, widely adopted libraries over custom implementations for cryptography or authentication

• Hard-code API keys, tokens, passwords, or any secrets in source code
• Commit .env.local or any file containing real credentials
• Disable TypeScript strict checks to work around type errors
• Use dangerouslySetInnerHTML without explicit sanitization (e.g., via DOMPurify)
• Suppress ESLint security rules without a documented reason
• Log sensitive user data to the console or external logging services
• Trust client-side data on the server without re-validation

AstroDex uses environment variables to manage sensitive configuration. Mishandling these is one of the most common sources of accidental secret exposure.

# .env.local.example — copy this file to .env.local and fill in real values

# Supabase (future integration)
NEXT_PUBLIC_SUPABASE_URL=your_supabase_project_url
NEXT_PUBLIC_SUPABASE_ANON_KEY=your_supabase_anon_key

# NASA API (if applicable)
NASA_API_KEY=your_nasa_api_key

⚠️ NASA_API_KEY does not use the NEXT_PUBLIC_ prefix because it should only be accessed server-side (e.g., in API routes or Server Components). Exposing it to the browser would allow anyone to use your quota.

1. Rotate the secret immediately — invalidate the exposed key before doing anything else
2. Remove the secret from the codebase
3. Use git filter-repo or BFG Repo Cleaner to purge it from Git history
4. Force-push the cleaned history
5. Notify the maintainer so the incident can be assessed

Third-party dependencies are a common attack vector. AstroDex uses the following practices to mitigate supply chain risk:

# Run a full audit of installed packages
npm audit

# Automatically fix low-risk vulnerabilities
npm audit fix

# Review high and critical vulnerabilities manually
npm audit --audit-level=high

Run npm audit regularly and always before opening a pull request.

• Do not add new dependencies lightly. Every dependency is a potential attack surface. Ask yourself whether the functionality can be achieved with what is already in the project or with native APIs.
• Evaluate packages before adding them:
  • Is it actively maintained?
  • Does it have a large number of dependents?
  • Does it have a clear security policy?
  • Are the weekly download numbers reasonable?
• Pin dependency versions in critical situations rather than relying on broad semver ranges
• Do not install packages from untrusted or unknown sources

The following are known areas of the codebase that require careful handling:

• GLSL shaders are compiled and executed on the GPU. While this is sandboxed by the browser, avoid injecting untrusted user input into shader source strings.
• Texture URLs loaded via useTexture should always point to trusted, controlled origins to prevent unexpected asset loading.

• The NASA API key should never be exposed to the client. All requests to the NASA API must be proxied through Next.js API routes or Server Components.
• Rate-limit API routes to prevent abuse and protect your API quota.

• Use Row Level Security (RLS) on all Supabase tables. Never rely solely on client-side checks to protect data.
• The anon key is safe to expose in the browser only when RLS policies are correctly configured.
• Validate all data on the server side in addition to any client-side validation.
• Use Supabase Auth for user identity — do not implement custom authentication unless absolutely necessary.

AstroDex follows a coordinated disclosure model:

1. Reporter submits a vulnerability privately
2. Maintainers acknowledge and assess the report
3. A fix is developed, tested, and released
4. A public security advisory is published after the fix is available
5. The reporter is credited in the advisory (unless they prefer to remain anonymous)

We ask that reporters:

• Give us a reasonable amount of time to address the issue before any public disclosure
• Avoid accessing, modifying, or deleting user data during any testing
• Act in good faith toward the security and privacy of the project and its users

In return, we commit to:

• Responding promptly and transparently
• Crediting researchers who report valid vulnerabilities
• Not pursuing legal action against good-faith security researchers

This security policy was last updated for the current state of the AstroDex main branch. It will be revised as the project grows and new integrations are added.