Improve security

Hi,

Those ideas sound really interesting.

I think you should post them here: https://www.ads-software.com/ideas/

WordPress should add Options -Indexes into the .htaccess

…

1. Add Options -Indexes and Header set X-Content-Type-Options “nosniff” in .htaccess

Not all Apache2 installations support putting Options in the .htaccess file so doing that by default would break LOTS of sites. It also doesn’t address the important point that some hosts configure their Apache2 sites badly.

Edit: Also while WordPress does produce an .htaccess file not everyone should depend on that. Many do run nginx too.

WordPress Username Enumeration – /?author={id} A flaw in WordPress makes it possible to enumerate which usernames are registered.

That’s a lengthy discussion and it’s not a flaw. ??

Obscured user names are not security, just ask any online social media service. They don’t hide user names for a good reason: you cannot protect your username and anything that you cannot protect has no business being part of a security strategy.

You are expected to protect your passwords and strong passwords are the security solution for denying unauthorized access. Like those online services you can add via a plugin two factor authentication.

Content Sniffing This may open up for XSS attacks as browsers will attempt to guess how to render specific resources without the correct policies.

Debatable. The javascript files on your site will get downloaded, setting the MIME type isn’t that difficult.

If you are concerned about authentication in the open (and I don’t think you are) then SSL is a valid option.

https://codex.www.ads-software.com/Administration_Over_SSL

Or switch your site to 100% based SSL (it’s TLS, industry labels are silly). That too is a server based option but it’s not hard if you know how.

Cookie is not set to be HttpOnly – /wp-login.php One or more cookies lack the flag HttpOnly-flag. If an attacker discovers an XSS he may use it to steal cookies which haven’t got the HttpOnly-flag.

WordPress cookies are indeed set to be HTTP-Only, with the exception of the “test cookie” in the wp-login.php file. The test cookie simply determines whether or not your browser has cookies enabled, in order to give you an error if they are not. It contains no actual content to steal, just the phrase “WP Cookie check”.

Empty Document – /wp-includes/Text/Diff.php Direct access
Empty Document – /wp-includes/admin-bar.php Direct access
Empty Document – /wp-includes/category-template.php Direct access

Many files in WordPress are directly accessible. This is by design. Any non-entry points (and WordPress has multiple entry points) are only function definitions. Calling them directly does nothing, since they have no main code paths. Adding defined( 'ABSPATH' ) or die and similar things adds no security if the file has no code that can run directly.

A testing tool, such as this “Detectify” you mention, is only as good as the tests it performs. Any results must be interpreted by knowledgeable people. Security is not black and white, not a binary situation.

Even the theme-check tool I write for theme authors to work with has flaws in its set of tests, and it will always have flaws. The purpose of such a tool is to be a *tool* to help find and improve issues. It is not a system of measurement against which you can judge quality.