Support » Plugin: BulletProof Security » [Plugin: BulletProof Security] Feature suggestion to avoid 403 errors

  • Resolved Daedalon


    First I want to express thanks to the author for his efforts for the WP community.

    I installed BPS 0.46.3 today on three WP 3.1.3 blogs of different ages and of different amounts of other plugins installed. The steps I did for each were to create backups, then “create secure .htaccess file” by AutoMagic, then activate BulletProof mode for each folder: root, wp-admin, BPS master htaccess and BPS backup, in that order.

    Two of the three blogs started giving me 403 Forbidden for all pages under /wp-admin/ instantly after clicking to activate the BulletProof mode for BPS master htaccess folder. Admin dashboard is now inaccessible for those two.

    Interestingly the blogs were the oldest and the newest one, which had virtually no plugins installed. If it had any, the other two blogs both had them as well. Since one of the blogs encountered no problems, I believe that a plugin conflict is not the cause.

    I’m very surprised that the feature supposedly for copying and renaming a .htaccess file to wp-content/plugins/bulletproof-security/admin/htaccess/ can block access to wp-admin/. Happening on two blogs at the exact same point – but not done at the exact same time – closes out most server configuration based causes that I can think of.

    1. What might be the cause of this error? Could it be something in my server or directory permission configuration?

    2. Suggestion: Make all changes done by BulletProof Security to require a user confirmation that the following page loads occurred correctly, and if the confirmation is not given in a reasonable time (e.g. 5 minutes), reverse the change. Optionally make it even more automatic: if any pages under wp-admin/ manage to be completely loaded during the next 5 minutes, keep the change, otherwise reverse it.

    This will avoid the admins being locked out of their admin panels in case anything goes wrong, for any reason, by any change.

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author AITpro


    I would need some specific information about your websites in order to be able to assist you.
    Are these standard WP installations? ie not Network or Buddypress?
    What is different about the site that is working? ie settings made by you in your WP dashboard or in your host CP.
    Folder permissions are usually not going to cause this issue, but with that said if you have manually changed your folder permissions for your wp-admin folder to not allow permissions to copy a file to the folder then it is possible the BPS /wp-admin htaccess files were never copied successfully.
    Have you set up any domain or subdomain forwarding or any othe DNS settings in your host control panel?

    Typically when you get 403 errors when trying to access admin areas of your site this usually means that the BPS /wp-admin htaccess file either has not been activated yet or does not really exist. So this is what you should check. You will need to manually verify that the new BPS htaccess files really do exist in your /wp-admin folders.

    Hmm very interesting suggestion. I like it. 😉 I will think about and explore all the pitfalls and problems that this would create and if not too many new problems are created then I’ll go ahead and write that code. For now you can manually FTP to your website or use your CP to just edit or delete or replace the new BPS htaccess files with your old htaccess files. Thanks.

    Thanks for the prompt reply. WP installations are standard single-site ones. The settings of all blogs are similar, but there are some differences and some different plugins. After I get the sites working again I can email you any info that would help you.

    Thinking quickly I can’t think of a reason why the “middle” blog continued to function, while the most modified and content-rich AND the just installed and barely touched blog both failed.

    A previous time in the spring a similar error happened to one of my blogs, don’t remember if it was the heavier or the middle one, where seemingly out of the I got locked out of the site. Don’t remember whether it was the whole site or just the admin panel, but that was resolved by changing the folder permissions. Then I hadn’t installed BPS, but W3 Total Cache was among the installed ones. I had a similar problem related to that this very day, where just installing it on the fresh blog caused it to completely 403 me, each and every page. Redeploying it on the middle blog – the one currently working – after installing BPS, resulted in 403 in the middle blogs wp-admin/ pages. Both issues were resolved by folder permissions, but after that, the fresh blog got this issue with BPS, the middle one didn’t.

    In case it is related to folder permissions that would not allow BPS to copy .htaccess succesfully to wp-admin/, how would that cause this 403? Would the previous one – if there was one – stop to exist? Or could it happen so that the .htaccess file gets copied, but its permissions are wrong? Or are the permissions handled in two parts, so that the part denying all gets copied, but the part allowing the correct users did not get copied?

    I haven’t used any subdomain features with the blogs. The heaviest and the middle one operate straight on the main level domain, like, without any subdomains such as www. The last one is on a subdomain of a different main level domain, like blog.organization.tld.

    Plugin Author AITpro


    In case it is related to folder permissions that would not allow BPS to copy .htaccess succesfully to wp-admin/, how would that cause this 403?

    Ok lets just address this issue because this will give you full understanding of what is happening with BPS and htaccess files. First off htaccess files work in a hierarchal way meaning that if a parent folder has an htaccess file (your root website folder) and a child folder (your wp-admin folder) does not have an htaccess file then the rules / directives in the parent folder are applied to the child folders. What happens is that URL rewriting is applied to the wp-admin folder. No URL rewriting should be occurring in your wp-admin folder. This will cause your admin area to either be completely inaccessible or to not function correctly. So it is absolutely essential that if a BPS root htaccess file is activated then a BPS wp-admin htaccess file must also be activated.

    The only permissions that would cause a problem would be your /wp-admin folder permissions itself. It should be 755. This is standard for WordPress folders and also secure. There is no need to change the WordPress 755 folder permissions on any of the WordPress application folders.

    It is also possible that the copy function itself is being blocked by something. This could be a setting your host has done in a master file or this could be a php.ini custom setting that you have done. There is also an issue with PHP4 that causes problems. I assume that BPS did not alert you about PHP4 running on the site? You may not have been able to see that error depending on when you got the 403 though. You should be running PHP5 not only for BPS to work correctly, but also because PHP4 is EOL. 😉

    So what you need to determine is the actual folder permission for your /wp-admin folder and to check if the BPS htaccess file was really copied to your /wp-admin folder. If the BPS htaccess file was not copied then either the copy function was blocked or the permissions for your /wp-admin folder are set incorrectly. Thanks.

    Thanks for the information. The blogs are functioning now. The problem was solved by the folder permissions. I received the following comment: “The plugins sometimes cause problems by chmodding .htaccess to 600, which does not go with suphp, which requires 644. 600 causes Apache to not be able to access the file, resulting in a 403 error.”

    After the admin panel recovery, both blogs showed this in the BPS status panel:

    √ wp-config.php is .htaccess protected by BPS
    √ php.ini and php5.ini are .htaccess protected by BPS

    Deny All protection NOT activated for BPS Master /htaccess folder
    Deny All protection NOT activated for /wp-content/bps-backup folder

    File / Folder Name – Path – Suggested Permissions – Current Permissions
    root folder ../ 755 755.
    wp-includes/ ../wp-includes 755 755.
    .htaccess ../.htaccess 644 644.
    wp-admin/.htaccess ../wp-admin/.htaccess 644 644.
    index.php ../index.php 644 644.
    wp-admin/index.php ../wp-admin/index.php 644 644.
    wp-admin/js/ ../wp-admin/js/ 755 755.
    wp-content/themes/ ../wp-content/themes 755 775.
    wp-content/plugins/ ../wp-content/plugins 755 775.
    wp-admin/ ../wp-admin 755 755.
    wp-content/ ../wp-content 755 755.

    Everything else was fine as far as I can see and as according to BPS except for the two missing BPS deny-alls.

    Adding the two deny-alls went without any hassle, and all three blogs are now running with BPS installed and all .htaccess security options activated.

    Now we can concentrate on figuring out exactly what caused the problem, can it be prevented by some additional checks, and if you will, implementing the auto-recovery I suggested. Thanks!

    Plugin Author AITpro


    good catch. hmm checking for suPHP or suExec would be a daunting task and not something i would like to attempt. This would be simple if i was only dealing with 1 web host instead of 100’s. 😉 Forcing the htaccess files to CHMOD to 644 is very simple so i will add that in the next release of BPS. So that would eliminate the need for a check.

    The auto recovery idea will take a lot of thought and actual scenario testing before i would implement it. I can already foresee about 15 problems with implementing it. So this would be a long term thing and not something that would happen in any of the near future releases of BPS.

    Well done on figuring this one out! Thanks.

    Good to hear about the forecoming update, thanks.

    In case checking for suphp comes handy later on, I think phpinfo() gives it. Another way is shown in and an example pseudo code using phpinfo() is located at, with the original poster of the question replying “thank you I can really make use of that”.

    Plugin Author AITpro


    Tep I’ve looked at methods like these in the past, but one is problematic and the other opens a security vulnerability, but thanks for the input. 😉

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘[Plugin: BulletProof Security] Feature suggestion to avoid 403 errors’ is closed to new replies.