This repository has been archived by the owner on Feb 23, 2019. It is now read-only.
"Security Headers" Section Added to Browser Cache #344
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
amiga-500
changed the title
amiga-500
changed the title
|
Great! |
amiga-500
added a commit
that referenced
this pull request
Feb 5, 2017
This is an amendment to #344 that adds in default values for the "Content Security Policy" fields and fixes grammatical errors in the "Security Headers" section.
amiga-500
added a commit
that referenced
this pull request
Feb 5, 2017
…ctions (#363) This is an amendment to #344 (the new "Security Headers" section to W3TC). Because the Content Security Policy (CSP) section can seem daunting at first for inexperienced users I felt it is important to include default values and placeholder field examples that users can rely on and use for this security feature. It makes for a better experience when using W3TC. This amendment also fixes some grammatical errors I discovered in the Security Headers section. Sorry.
amiga-500
added a commit
that referenced
this pull request
Feb 13, 2017
This is dependent on #344 and #363 and relates to the Security Headers management of Session Cookies. Previously, it was using the .htaccess (or nginx.conf) file to set those security options. But because each user's environment is different there isn't an assurance of the needed privileges to modify php values from said files. As such, this management was shifted to be handled in code entirely, which is a better approach. It slipped my mind that session cookies are generated in php during a non-cached session. My original, and mistaken, oversight was that i needed to continually have these session cookie security settings always configured (via the htaccess/nginx.conf) even during cached page servings, which isn't true. Those settings are important only when the session is generated -- during a non-cached period. So this fix resolves that.
szepeviktor
pushed a commit
that referenced
this pull request
May 5, 2017
Furniel
added a commit
that referenced
this pull request
Dec 24, 2017
|
@nigrosimone This is not great at all There should be a red warning in the General Settings page after activating w3tc that w3tc has disabled all set security headers, or else few if any wordpress admins will realize they have to laboriously set the headers again within w3tc's individual fields. Note that in functions.php they will have easily set security headers as they can write all in one block. In w3tc this isn't even possible. Having clarified that, the feature itself is of course much welcomed within w3tc, or indeed any caching plugin. It again shows how up to date Frederick Townes is. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This new feature is called Security Headers and is a new section that resides at the bottom of the Browser Cache page. With it the user can manage and lock down aspects of their website using extensive security header details. When making use of all of its options one will see results that look like this ...
Scan Results (W3TC using Security Headers) - via SecurityHeaders.io:
Because W3TC is a robust cache plugin, with caching at its core, it makes it difficult for security header plugins to function correctly. It's because these third-party plugins seem to depend heavily on live pages triggering them. Since W3TC serves cached pages this destroys their workflow, and pages only function correctly when using them once per cache refresh. This leaves the user with only two options: manually generate their own security headers or look to W3TC to provide it for them. I chose the latter option 🙉
The Security Headers section provides user customizable security details for the following items (also see attached images):
X-Frame-OptionsX-XSS-ProtectionX-Content-Type-OptionsHTTP Public Key PinningContent Security PolicyAccess session cookies through the HTTP protocol onlySend session cookies only to secure connectionsUse cookies to store session IDs in the user's browserHTTP Strict Transport Security policy(Note: This already existed but was moved into this section and extended with more options)
Browser Cache: Security Headers
Content Security Policy - Quick Reference Chart: