Security Headers

Site Feedback
1

What do you all think about updating the Header portion of the user guide to show some security headers? Something like the basic example below could be added. Hopefully having such an example will remind folks to think about adding such headers to their sites.

header / {
  Strict-Transport-Security "max-age=31536000;"
  X-Content-Type-Options "nosniff"
  X-Frame-Options "DENY"
  X-XSS-Protection "1; mode=block"
  -Server
}

Also, I recommend revising the last example on the Header User Guide page from header / X-Backend-Server {hostname} to header / X-Backend-Server {host}. Showing an example which returns the host portion of the request rather than the OS level server hostname seems safer (i.e., folks copying the examples won’t inadvertently configure Caddy to leak information which could aid a hacker gathering information to tailor exploits). Admittedly, this is a bit of security by obscurity, but it’s still better to not give away any more details than necessary.

If anyone wants to learn more about security headers, the following are good references/tools:

3 Likes
2

I wouldn’t object to this. I didn’t know about security headers.

3

I think it’s a good idea, as long as each header was commented with what it means. For example, HSTS isn’t a good idea for a site that’s still experimenting with HTTPS (not really an issue with Caddy, but still).

I recommend revising the last example on the Header User Guide2 page from header / X-Backend-Server {hostname} to header / X-Backend-Server {host}.

We could do that; is that helpful though? That’s just the host portion of the request.

1 Like
4

Thanks. Good thinking about adding a comment to each header to explain their meeting. You’re note about HSTS is a good observation. Along those same lines, I specifically avoided suggesting anything about HPKP because it’s too easy for someone who isn’t fully aware of the ramifications associated with it to make their domain inaccessible. While the benefits of HPKP are tremendous, I don’t think we should mention it in the Caddy docs because it may cause more problems/questions than the Caddy community should support. People who want and know about HPKP won’t need the Caddy docs to help implement it.

We could do that; is that helpful though? That’s just the host portion of the request.

It’s probably not helpful in and of itself. My thought was more that the example X-Backend-Server header might cause people to disclose more internal details about their environment than they should. Using {host} in lieu of it would still allow the example to work without leaking too much detail. To your point though, providing the host portion of the request in the header isn’t valuable. Given this, my real preference would be do either do away with the example X-Backend-Server header or replace it with another example. However, the existing X-Backend-Server example is not a significant risk so I would understand if you opted not to do anything.

Let me know if you want me to help draft up some comment wording for example security headers.

5

Sure, go ahead and submit a PR and make the examples better for the headers docs. That’d be great! (Remember though, the topic of the page is headers, not security.)

6

I’ll give it go, but you’ll have to point me to the repo. I didn’t find it when I searched.

7

It’s at https://github.com/caddyserver/caddyserver.com :slight_smile:

8

Thanks. I kept looking under mholt (Matt Holt) · GitHub :blush:

9

PR submitted. Tried to keep it short, sweet, and on topic. Feel free to revise.

1 Like