Title: Improve security
Last modified: August 30, 2016

---

# Improve security

 *  [allegroclub](https://wordpress.org/support/users/allegroclub/)
 * (@allegroclub)
 * [10 years, 11 months ago](https://wordpress.org/support/topic/improve-security/)
 * WordPress installation now automatically create .htaccess file. WordPress should
   add `Options -Indexes` into the .htaccess, so non-real file/folder without permission
   will get 404 error without the need of placing empty index.html/index.php. This
   should also eliminate some security notices when user ran security checks on 
   wordpress sites.
 * After I ran a test against my installation on WordPress 4.3.1 multisites, Detectify
   gave me following warnings.
    - **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 Username Enumeration – /?author={id}** A flaw in WordPress makes
      it possible to enumerate which usernames are registered. An attacker can use
      this information in another step of an attack, for example trying common passwords
      against the users, spear fishing or social engineering.
    - **Content Sniffing** This may open up for XSS attacks as browsers will attempt
      to guess how to render specific resources without the correct policies.
    - **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
 * Therefore, I recommend:
    1. Add `Options -Indexes` and `Header set X-Content-Type-Options "nosniff"` in .
       htaccess
    2. Remove all index.php/index.html from wordpress directories
    3. Add `defined( 'ABSPATH' ) or die( 'No script kiddies please!' );` into php file
       header Ref. [https://codex.wordpress.org/Writing_a_Plugin#Plugin_Files](https://codex.wordpress.org/Writing_a_Plugin#Plugin_Files)
 * Thanks!

Viewing 3 replies - 1 through 3 (of 3 total)

 *  [Colin McDermott](https://wordpress.org/support/users/woodsandhillsplc/)
 * (@woodsandhillsplc)
 * [10 years, 11 months ago](https://wordpress.org/support/topic/improve-security/#post-6659158)
 * Hi,
 * Those ideas sound really interesting.
 * I think you should post them here: [https://wordpress.org/ideas/](https://wordpress.org/ideas/)
 *  Moderator [Jan Dembowski](https://wordpress.org/support/users/jdembowski/)
 * (@jdembowski)
 * Forum Moderator and Brute Squad
 * [10 years, 11 months ago](https://wordpress.org/support/topic/improve-security/#post-6659159)
 * > 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](https://wordpress.org/support/topic/wordpress-vulnerability-3?replies=13)
   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.wordpress.org/Administration_Over_SSL](https://codex.wordpress.org/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.
 *  Moderator [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * (@otto42)
 * WordPress.org Admin
 * [10 years, 11 months ago](https://wordpress.org/support/topic/improve-security/#post-6659210)
 * > 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.

Viewing 3 replies - 1 through 3 (of 3 total)

 The topic ‘Improve security’ is closed to new replies.

 * In: [Requests and Feedback](https://wordpress.org/support/forum/requests-and-feedback/)
 * 3 replies
 * 4 participants
 * Last reply from: [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * Last activity: [10 years, 11 months ago](https://wordpress.org/support/topic/improve-security/#post-6659210)
 * Status: not resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics