Weston Ruter

This plugin enforces a <a href="https://web.dev/articles/strict-csp" rel="nofollow ugc">Strict Content Security Policy</a> (CSP) on the frontend and login screen. This helps mitigate <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS" rel="nofollow ugc">cross-site scripting</a> (XSS) vulnerabilities. The policy cannot yet be applied to the WP Admin (see <a href="https://core.trac.wordpress.org/ticket/59446" rel="nofollow ugc">#59446</a>).
In <a href="https://core.trac.wordpress.org/ticket/58664" rel="nofollow ugc">#58664</a>, the manual construction of script tags was eliminated from <code>WP_Scripts</code> and inline scripts on frontend/login screen, thanks to the helper functions which had previously been introduced in <a href="https://core.trac.wordpress.org/ticket/39941" rel="nofollow ugc">#39941</a>. This made it possible to apply Strict CSP, as long as themes and plugins are not directly printing <code><script></code> tags. Some bundled WordPress core themes <a href="https://github.com/search?q=repo%3AWordPress%2Fwordpress-develop+path%3A%2F%5Esrc%5C%2Fwp-content%5C%2Fthemes%5C%2F%2F+%2F%3Cscript%5B%5E%3E%5D*%3E%2F&type=code" rel="nofollow ugc">still do this</a> incorrectly (which has been reported in Trac as <a href="https://core.trac.wordpress.org/ticket/63806" rel="nofollow ugc">#63806</a>). For example, do not do this:
<pre>function my_theme_supports_js() {
 echo '<script>document.body.classList.remove("no-js");</script>'; // ❌
}
add_action( 'wp_footer', 'my_theme_supports_js' );</pre>
Instead, do this:
<pre>function my_theme_supports_js() {
 wp_print_inline_script_tag( 'document.body.classList.remove("no-js");' ); // ✅
}
add_action( 'wp_footer', 'my_theme_supports_js' );</pre>
So in order for scripts to execute, they must be printed using the relevant APIs in WordPress for adding scripts, including <a href="https://developer.wordpress.org/reference/functions/wp_enqueue_script/" rel="nofollow ugc"><code>wp_enqueue_script()</code></a>, <a href="https://developer.wordpress.org/reference/functions/wp_add_inline_script/" rel="nofollow ugc"><code>wp_add_inline_script()</code></a>, <a href="https://developer.wordpress.org/reference/functions/wp_localize_script/" rel="nofollow ugc"><code>wp_localize_script()</code></a>, <a href="https://developer.wordpress.org/reference/functions/wp_print_script_tag/" rel="nofollow ugc"><code>wp_print_script_tag()</code></a>, <a href="https://developer.wordpress.org/reference/functions/wp_print_inline_script_tag/" rel="nofollow ugc"><code>wp_print_inline_script_tag()</code></a>, and <a href="https://developer.wordpress.org/reference/functions/wp_enqueue_script_module/" rel="nofollow ugc"><code>wp_enqueue_script_module()</code></a>. Otherwise, a script’s execution will be blocked and an error will appear in the console, for example:
<blockquote>
Refused to execute inline script because it violates the following Content Security Policy directive: “script-src ‘nonce-9b539cfe47’ ‘unsafe-inline’ ‘strict-dynamic’ https: http:”. Note that ‘unsafe-inline’ is ignored if either a hash or nonce value is present in the source list.
</blockquote>
This also blocks scripts inside of <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes#event_handler_attributes" rel="nofollow ugc">event handler attributes</a>, such as <code>onclick</code>, <code>onchange</code>, <code>onsubmit</code>, and <code>onload</code>. As noted on MDN:
<blockquote>
Warning: The use of event handler content attributes is discouraged. The mix of HTML and JavaScript often produces unmaintainable code, and the execution of event handler attributes may also be blocked by content security policies.
</blockquote>
This plugin also ensures that scripts added to the page from embeds (e.g. Tweets) also get the <code>nonce</code> attribute added.

Strict CSP

Enforces a Strict Content Security Policy on the frontend and login screen to help mitigate any XSS vulnerabilities.

johanee

Limit the number of login attempts possible both through normal login as well as using auth cookies.
By default WordPress allows unlimited login attempts either through the login page or by sending special cookies. This allows passwords (or hashes) to be brute-force cracked with relative ease.
Limit Login Attempts blocks an Internet address from making further attempts after a specified limit on retries is reached, making a brute-force attack difficult or impossible.
Features
<ul>
<li>Limit the number of retry attempts when logging in (for each IP). Fully customizable</li>
<li>Limit the number of attempts to log in using auth cookies in same way</li>
<li>Informs user about remaining retries or lockout time on login page</li>
<li>Optional logging, optional email notification</li>
<li>Handles server behind reverse proxy</li>
<li>It is possible to whitelist IPs using a filter. But you probably shouldn’t. 🙂</li>
</ul>
Translations: Bulgarian, Brazilian Portuguese, Catalan, Chinese (Traditional), Czech, Dutch, Finnish, French, German, Hungarian, Norwegian, Persian, Romanian, Russian, Spanish, Swedish, Turkish
Plugin uses standard actions and filters only.

Limit Login Attempts

bad role

We had initial issues and tried again and it is working better.

Getting a lot better.


I absolutely hate bloated plugins, so I love this one. It's simple and works as expected. Guess it's wise to use a plugin such as this one, against brute force attacks.



Guido


Love this plugin

Limit rate of login attempts, including by way of cookies, for each IP. Fully customizable.

Strict CSP vs Limit Login Attempts