143 lines
4.8 KiB
Markdown
143 lines
4.8 KiB
Markdown
# Security Policy
|
|
|
|
## Supported Versions
|
|
|
|
We provide security updates for the following versions:
|
|
|
|
| Version | Supported |
|
|
| ------- | ------------------ |
|
|
| 1.0.x | :white_check_mark: |
|
|
| < 1.0 | :x: |
|
|
|
|
## 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](https://git.4nkweb.com/4nk/story-research-zapwall/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](https://owasp.org/www-project-top-ten/)
|
|
- [Node.js Security Best Practices](https://nodejs.org/en/docs/guides/security/)
|
|
- [Next.js Security](https://nextjs.org/docs/app/building-your-application/configuring/security-headers)
|
|
|
|
Thank you for helping keep zapwall4Science secure!
|