Completely re-reading the security book

| Q             | A
| ------------- | ---
| Doc fix?      | no
| New docs?     | no
| Applies to    | all
| Fixed tickets | n/a

Well, this should be interesting :). Several years ago, I bootstrapped the security chapter and it's been there ever since. That fact doesn't necessarily mean that it was good. I've just re-read and basically re-written the chapter from scratch. I thought it was too long, too theoretical in the beginning, and it also had some extra "baggage" just from being old and having things added to it.

My goal is to:

A) Not actually remove anything of importance - I've done my best with this
B) Actually get feedback that this is better. I feel that this is better, but rewrites aren't automatically better. It's like the second album of a band - even though they're older and wiser, maybe the original is still better :). I hope not!

Todo:

- [ ] fill in config blocks - @xabbuh if you happen to have some time and can help, I would be even more in debt to you :)

As I merge to 2.5 and up, I'll need to check for the `versionadded` tags on each branch and re-add those things to the new chapter.

Thanks!
This does not work for ESI, because Varnish sends the client IP in its ESI requests too (so that they can depend on the client IP). there is no way to know whether the request was initiated by Varnish or forwarded by it, unless you use a custom VCL config to add a header in ESI requests initiated by Varnish.
This is why controller-based URLs must now always be signed even for ESI: http://symfony.com/blog/cve-2014-5245-direct-access-of-esi-urls-behind-a-trusted-proxy (it was already signed for hinclude).

You need to find a better use case for securing by IP (maybe restricting the access to the internal network of your company)