-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebSockets / WebRTC / WebTransport #32
Comments
I think the most important is preventing HTTP connections, because private websites are most likely to be exploited via HTTP requests. Preventing any web traffic is probably a tad bit less important, but still useful - one can imagine buggy servers mishandling malicious malformed data, or even vulnerable websocket server implementations. I have not yet formed an opinion regarding WebRTC and WebTransport. |
WebSocket is essentially an HTTP connection, so it would have to be covered. WebTransport uses ALPN so maybe that is fine indeed. We would need to make it very clear that not all browser connections to these network addresses are preflighted. Unsure about WebRTC as well, but looking into it. |
Given that we had to expand port blocking to WebRTC, it would make sense to me that this also applies there. |
I'm curious where the hook for CORS RFC1918 should be. Is it primarily about HTTP connections, or is it about protecting specific IP addresses in general from web traffic?
The text was updated successfully, but these errors were encountered: