# 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!