|
| 1 | +# Security Policy |
| 2 | + |
| 3 | +## Supported Versions |
| 4 | + |
| 5 | +We release patches for security vulnerabilities for the following versions: |
| 6 | + |
| 7 | +| Version | Supported | |
| 8 | +| ------- | ------------------ | |
| 9 | +| main | :white_check_mark: | |
| 10 | +| latest release | :white_check_mark: | |
| 11 | + |
| 12 | +## Reporting a Vulnerability |
| 13 | + |
| 14 | +We take the security of this project seriously. If you discover a security vulnerability, please report it responsibly. |
| 15 | + |
| 16 | +### How to Report |
| 17 | + |
| 18 | +**Please do not report security vulnerabilities through public GitHub issues.** |
| 19 | + |
| 20 | +Instead, please report them via GitHub's private vulnerability reporting feature: |
| 21 | + |
| 22 | +1. Go to the [Security tab](https://github.com/LessUp/webrtc/security) |
| 23 | +2. Click "Report a vulnerability" |
| 24 | +3. Fill out the form with details about the vulnerability |
| 25 | + |
| 26 | +### What to Include |
| 27 | + |
| 28 | +Please include the following information: |
| 29 | + |
| 30 | +- Type of vulnerability (e.g., XSS, injection, DoS) |
| 31 | +- Steps to reproduce the issue |
| 32 | +- Affected versions |
| 33 | +- Potential impact |
| 34 | +- Any potential fixes you've identified |
| 35 | + |
| 36 | +### Response Timeline |
| 37 | + |
| 38 | +- **Initial response**: Within 48 hours |
| 39 | +- **Triage and confirmation**: Within 7 days |
| 40 | +- **Fix development**: Depends on severity and complexity |
| 41 | +- **Disclosure**: After a fix is released |
| 42 | + |
| 43 | +## Security Best Practices |
| 44 | + |
| 45 | +When deploying this WebRTC signaling server: |
| 46 | + |
| 47 | +### Network Security |
| 48 | + |
| 49 | +- Always use HTTPS/WSS in production |
| 50 | +- Configure `WS_ALLOWED_ORIGINS` to restrict which origins can connect |
| 51 | +- Use a reverse proxy (e.g., Caddy, Nginx) with proper security headers |
| 52 | + |
| 53 | +### Server Hardening |
| 54 | + |
| 55 | +- Run the server with minimal privileges |
| 56 | +- Keep dependencies updated |
| 57 | +- Monitor logs for suspicious activity |
| 58 | +- Consider rate limiting at the network level |
| 59 | + |
| 60 | +### WebRTC Security |
| 61 | + |
| 62 | +- For production, configure TURN servers with proper authentication |
| 63 | +- Be aware that WebRTC reveals IP addresses to peers |
| 64 | +- Consider using a TURN server to hide client IPs |
| 65 | + |
| 66 | +## Known Security Considerations |
| 67 | + |
| 68 | +### Authentication |
| 69 | + |
| 70 | +This server does not implement authentication. Anyone who knows a room name can join. For production use: |
| 71 | + |
| 72 | +- Implement your own authentication middleware |
| 73 | +- Use short-lived, randomly generated room names |
| 74 | +- Consider integrating with an identity provider |
| 75 | + |
| 76 | +### Rate Limiting |
| 77 | + |
| 78 | +The server implements basic rate limiting per connection: |
| 79 | +- Maximum 50 messages in burst |
| 80 | +- Maximum 30 messages per second sustained |
| 81 | + |
| 82 | +For additional protection, consider: |
| 83 | +- IP-based rate limiting at the reverse proxy |
| 84 | +- Connection limits per IP |
| 85 | +- Request size limits |
| 86 | + |
| 87 | +## Security Updates |
| 88 | + |
| 89 | +Security updates will be announced via: |
| 90 | +- GitHub Security Advisories |
| 91 | +- Release notes |
| 92 | + |
| 93 | +## Credits |
| 94 | + |
| 95 | +We thank all security researchers who responsibly report vulnerabilities. |
0 commit comments