Skip to content
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

LCD and RPC endpoints to expose security headers #4304

Closed
joe-bowman opened this issue May 8, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@joe-bowman
Copy link
Contributor

commented May 8, 2019

Summary

Cosmos RPC and light client endpoints should return HTTP security headers.

Problem Definition

A recent penetration test suggested that our public facing RPC/LCD nodes should expose the following headers in the response:

X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Cache-control: no-store, no-cache
Pragma: no-cache
Referrer-Policy: no-referrer
Feature-Policy: geolocation 'none'; midi 'none'; notifications 'none'; push 'none'; sync-xhr 'none'; microphone 'none'; camera 'none'; magnetometer 'none'; gyroscope 'none'; speaker 'none'; vibrate 'none'; fullscreen 'none'; payment 'none';

I'm caught between whether these headers ought to be exposed by the clients themselves, or whether we should introduce a load balancer (which is our current workaround) to enforce these headers.

Your thoughts are appreciated :)

Proposal

RPC and LCD should (optionally?) expose the HTTP security headers listed above.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@alexanderbez

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

My gut tells me these should be handled at the proxy layer. What are your thoughts?

@joe-bowman

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

On reflection, I'm inclined to agree. These are only a concern when exposing publically anyway, in which case best practice dictates running behind a reverse proxy anyway.

@joe-bowman joe-bowman closed this May 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.