story-research-zapwall/SECURITY.md

Security Policy

Supported Versions

We provide security updates for the following versions:

Version	Supported
1.0.x	✅
< 1.0	❌

Reporting a Vulnerability

We take security vulnerabilities seriously. If you discover a security vulnerability, please follow these steps:

1. Do NOT create a public issue

Security vulnerabilities should be reported privately to protect users.

2. Report via Private Issue

1. Go to the Issues page
2. Create a new issue with the title prefixed with [SECURITY]
3. Mark the issue as confidential/private if Gitea supports it
4. Fill out the form with:
   • Title: Brief description of the vulnerability (prefixed with [SECURITY])
   • Description: Detailed description of the vulnerability
   • Severity: Assess the severity (Low, Moderate, High, Critical)
   • Affected versions: Which versions are affected
   • Steps to reproduce: How to reproduce the vulnerability
   • Impact: What could an attacker do with this vulnerability

3. Alternative Reporting Methods

If you cannot create a private issue, please contact the maintainers directly through secure channels. Do not disclose the vulnerability publicly until it has been addressed.

4. What to Include

Please include the following information in your report:

• Type of vulnerability (e.g., XSS, CSRF, authentication bypass, etc.)
• Location (file path, component, or endpoint)
• Steps to reproduce (detailed steps)
• Potential impact (what could an attacker do?)
• Suggested fix (if you have one)
• Proof of concept (if applicable, but be careful not to include exploits)

5. Response Timeline

• Initial response: Within 48 hours
• Status update: Within 7 days
• Fix timeline: Depends on severity
  • Critical: As soon as possible (typically within 24-48 hours)
  • High: Within 1 week
  • Medium: Within 2 weeks
  • Low: Within 1 month

6. Disclosure Policy

• We will acknowledge receipt of your report within 48 hours
• We will keep you informed of our progress
• We will notify you when the vulnerability is fixed
• We will credit you in the security advisory (unless you prefer to remain anonymous)

Security Best Practices

For Contributors

• Never commit secrets: API keys, private keys, passwords, etc.
• Use secure dependencies: Keep dependencies up to date
• Follow secure coding practices: Input validation, output encoding, etc.
• Review security implications: Consider security impact of changes

For Users

• Keep dependencies updated: Run npm audit regularly
• Use HTTPS: Always use HTTPS in production
• Secure your Nostr keys: Never share your private keys
• Use secure Lightning wallets: Only use trusted Lightning wallet extensions

Known Security Considerations

Nostr Authentication

• Private keys are managed by the Alby extension (NIP-07)
• We never store or transmit private keys
• All Nostr operations are signed client-side

Lightning Payments

• Payment requests are generated via WebLN (Alby extension)
• We do not handle private keys or payment secrets
• All payment operations are performed by the user's wallet

Data Storage

• Private content is encrypted using AES-GCM
• Encryption keys are stored in browser localStorage
• No sensitive data is sent to external servers (except Nostr relays)

IndexedDB

• Encrypted content is stored in IndexedDB
• Keys are derived from a master key stored in localStorage
• Content expires after 30 days

Security Updates

Security updates will be announced via:

• Security advisories in issues
• Release notes
• Project documentation

Responsible Disclosure

We appreciate responsible disclosure. If you follow these guidelines, we will:

• Work with you to understand and resolve the issue quickly
• Credit you in our security advisory (if desired)
• Not take legal action against you

Security Checklist for Pull Requests

Before submitting a PR, ensure:

• No hardcoded secrets or credentials
• Input validation is implemented
• Output is properly encoded/escaped
• Error messages don't leak sensitive information
• Dependencies are up to date (npm audit)
• No console.log statements with sensitive data
• Authentication/authorization is properly implemented
• HTTPS is used for all external requests

Additional Resources

• OWASP Top 10
• Node.js Security Best Practices
• Next.js Security

Thank you for helping keep zapwall4Science secure!