LCD and RPC endpoints to expose security headers

[joe-bowman]

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]

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

[joe-bowman]

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.