POST Request Protection|POST Attack Protection|POST Request Blocker

Home Forums BulletProof Security Pro POST Request Protection|POST Attack Protection|POST Request Blocker

Viewing 15 posts - 16 through 30 (of 34 total)
  • Author
  • #29644

    Hi, I have some Qs about the code
    [existing code was deleted – no need to repost the existing code in this Topic as a reference]
    Qs are:
    1) in the RewriteRule, why do ^(.*) when we do not care what the request is and could just match against ^ instead?

    2) where are the [OR] flags? (also, there is no [NC] in your example for /wp-admin/customize.php)
    …as is it seems to me that this won’t work:

    ‘ornext|OR’ (or next condition)
    Use this to combine rule conditions with a local OR instead of the implicit AND. Typical example:

    RewriteCond "%{REMOTE_HOST}"  "^host1"  [OR]
    RewriteCond "%{REMOTE_HOST}"  "^host2"  [OR]
    RewriteCond "%{REMOTE_HOST}"  "^host3"

    Without this flag you would have to write the condition/rule pair three times.

    ( also found a very nice answer at )
    …yet I assume that you’ve tested your code, and that you generally know more than I do about htaccess =)
    …still, it seems to me that it should be something like this

    # BPS POST Request Attack Protection
    RewriteCond %{REQUEST_METHOD} POST [NC]
    RewriteCond %{REQUEST_URI} !^.*/wp-admin/ [NC,OR]
    RewriteCond %{REQUEST_URI} !^.*/wp-cron.php [NC,OR]
    RewriteCond %{REQUEST_URI} !^.*/wp-login.php [NC,OR]
    # Whitelist the WordPress Theme Customizer
    RewriteCond %{HTTP_REFERER} !^.*/wp-admin/customize.php [NC,OR]
    # Whitelist XML-RPC Pingbacks, JetPack and Remote Posting POST Requests
    RewriteCond %{REQUEST_URI} !^.*/xmlrpc.php [NC,OR]
    # Whitelist Network|Multisite Signup POST Form Requests
    RewriteCond %{REQUEST_URI} !^.*/wp-signup.php [NC,OR]
    # Whitelist Network|Multisite Activate POST Form Requests
    RewriteCond %{REQUEST_URI} !^.*/wp-activate.php [NC,OR]
    # Whitelist Trackback POST Requests
    RewriteCond %{REQUEST_URI} !^.*/wp-trackback.php [NC,OR]
    # Whitelist Comments POST Form Requests
    RewriteCond %{REQUEST_URI} !^.*/wp-comments-post.php [NC,OR]
    # Example 1: Whitelist Star Rating Calculator POST Form Requests
    RewriteCond %{REQUEST_URI} !^.*/star-rating-calculator.php [NC,OR]
    # Example 2: Whitelist Contact Form POST Requests
    RewriteCond %{REQUEST_URI} !^.*/contact/ [NC,OR]
    # Example 3: Whitelist PayPal IPN API Script POST Requests
    RewriteCond %{REQUEST_URI} !^.*/ipn_handler.php [NC]
    RewriteRule ^(.*)$ - [F]

    (assuming one is using the examples at the end as well – the last RewriteCond does not have an [OR] flag)

    Thoughts? Elucidations?

    Cheers, Max

    AITpro Admin

    1.  Done out of habit/routine and yep the code could be created differently using several different ways.
    2. Request method POST would not have an OR flag because every RewriteCond is checking POST “and” X. All other other RewriteCond’s could use OR, but I didn’t bother to add OR because the conditions are “is not” and not “is”, which would require using OR. The NC flag means match a case-insensitive string or in other words match ABCD or abcd. The last condition should never have an OR flag because there are no other “or” conditions after the last condition.

    Oh and thanks for spotting the missing NC for the customize.php condition.  I have added it in the Bonus Custom Code.  Technically none of the conditions need an NC flag, but once again done out of habit/routine. 😉


    Thanks for replies =)

    Request method POST would not have an OR flag because every RewriteCond is checking POST “and” X.

    duh, I was in a rush… (have edited my example)

    didn’t bother to add OR because the conditions are “is not” and not “is”, which would require using OR

    oh, well… I didn’t know about that… got some googling to do
    [edit: thanks for reply

    If the Request is a POST Request and the URL is not X and the URL is not Y and the URL is not Z

    very helpful… perhaps I should also write things out before asking]

    Cheers, Max

    AITpro Admin

    Yeah I figured that was just a typo, but mentioned it anyway just in case.  The simple way to look at the conditions is to use your “fingers and toes to count”, which I always have to do especially when it comes to creating literal “math” functions.  ie if X > Y – Z + W.  So I always write it out in plain english to make sure I am not going to do something dumb. 😉

    Example:  If the Request is a POST Request and the URL is not X and the URL is not Y and the URL is not Z…. then block any/all other POST Requests made by a dummy hacker or spammer.

    The flip side of that coin would be: If X action is done and the matching pattern “is equal to” a condition then you need to use OR flags for each condition otherwise you end up matching hierarchically and things would obviously break.  Ie if X = Y or A = B…

    Oh and no need to fill in the silly “Optional reason for editing” text box.  That is on my list of things to get rid of in this forum. 😉  I find that same thing very irritating on StackOverflow.  ie of course I am fixing or adding something else so why ask me about that.  😉


    yeah, its generally pretty useless…

    …its an open field and I’m a sucker for documentation so sometimes I find myself filling it out for no good reason, sometimes just for fun =)

    Thanks for being awesome, really appreciate your time in responding.

    Cheers, Max



    I have a Gravity Form that appears on three pages, including the home page. With reference to your examples, I’m fine to try whitelisting the other two pages, but how would I go about whitelisting the home page?

    Thanks for your help!


    AITpro Admin

    @ Jenn – The answer is you would not want to do that.  The reason for that is because the most common primary attack vector IS your website Root URI|Home page.  hackers commonly send POST Request attacks to your website Root URI|URL.  So if you whitelist your Root URI|URL then you have effectively removed/whitelisted the hacker’s attack.  Or in other words, you have negated the POST Attack Protection code.  Forms should be on their own individual pages for a number of good/safe website design reasons.



    I’ve added the POST request protection custom code to my site and commented out any white listings (including the comment form and the WP customizer) except of the first must-haves on top to make sure, it does really block the POST requests. However, it doesn’t block anything. I can still post a comment or change the layout in the customizer.

    Any suggestions about the reason?


    AITpro Admin

    @ Qtwix – You would not want to block people from being able to post comments on your Comments Form.  This whitelist rule below allows/whitelists posting comments to your wp-comments-post.php file, which is your site’s Comments Form.  Your Comments Form already has validation and sanitization security code in it to make sure only valid safe content is entered into your Comments Form Fields.  The primary purpose of the BPS POST Attack Protection code is to block POST Requests that are made to your Root website URL.  Typically 99% of all hacker POST Attacks are made to your Root website URL.

    # Whitelist Comments POST Form Requests
    RewriteCond %{REQUEST_URI} !^.*/wp-comments-post.php [NC,OR]

    If you commented out the Comments Form whitelist rule above and comment posting was not blocked then either you did not do all of the Custom Code steps or your site is using some kind of custom Comments Form that does not use the wp-comments-post.php form. When I post comments with the Comments Form whitelist rule commented out I see this URI: and the BPS 403 Error page.

    The WordPress Customizer has been changed by the WP folks in a recent version of WP so the Customizer whitelist rule is no longer needed and does not do anything anymore.


    Thanks! Actually I didn’t really want to block the comment form. In a first step I just tested the email form of one of the productive sites without whitelisting it and realised that the mail was sent anyway. So, I progressed to see, if the comment form will get blocked the POST request if the according line is commented out. I just wanted to check if the 404 error will really appear and what the log will look like. But as I wrote, It was not blocked at all. By the way, it’s the site you were logged in last week about the MIME type issue with .js files. Just let me know if you want to have another look on the website, I’ll send you the login details again…
    P.S. I currently have another issue posted, maybe they have something to do with each other:

    AITpro Admin

    @ Qtwix – See my last reply in your other forum topic.  It’s very possible that this is another host server problem.

    AITpro Admin

    @ Qtwix – I just testing posting a comment on your site.  While I was doing that I checked for any errors using Google Chrome Developer tools and I see this error:  Refused to execute script from '' because its MIME type ('text/x-js') is not executable, and strict MIME type checking is enabled. This is same javascript problem/error that was occurring on the backend of your website. What is really odd about this error is that other js scripts are not displaying this error. Only the wp-emoji-release.min.js script is generating this error??? I don’t think this error is that critical, but most likely WP Emojis will not work on your server/site due to whatever server configuration problem is still occurring on your host server.

    AITpro Admin

    @ Qtwix – Try removing this custom code from BPS Custom Code. It is possible that since BPS Speed Boost Cache code is already doing this then this code could be duplicating DEFLATE and causing problems. Also there are some known issues with using gzip and deflate with https/ssl sites, but I believe this issue is a loophole in TLS security and not a functionality type of problem.

    # Compress Components
    <FilesMatch "\\.(js|css|html|htm|php|xml)$">
    SetOutputFilter DEFLATE
    <IfModule mod_gzip.c>
    mod_gzip_on Yes
    mod_gzip_dechunk Yes
    mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
    mod_gzip_item_include handler ^cgi-script$
    mod_gzip_item_include mime ^text/.*
    mod_gzip_item_include mime ^application/x-javascript.*
    mod_gzip_item_exclude mime ^image/.*
    mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
    # Compress Components
    AITpro Admin

    @ Qtwix – Another possible solution that may be needed to override whatever is misconfigured/fubar on your server is this one in this StackOverflow topic:

    The AddType directive should be sufficient enough unless there’s something that’s forcing the type, but you can also try:

    <Files "*.js">
        ForceType text/javascript

    A better solution may be to look through your vhost/server config and all of the apache config files (that may be included by default in your config) for instances of application/x-javascript to see how that’s being set. It may be better to just change it there instead of htaccess file, which may not have the neccessary override options (mod_mime’s AddType and ForceType, for example, require the FileInfo AllowOverride option).

    AITpro Admin

    @ Qtwix – I logged into your site and now see that your server security policy is causing all of the problems.

    Ok yeah this is the first clue to all of the problems you are experiencing with your host server.  When I tried to edit the Root htaccess file directly using the BPS Pro htaccess File Editor I saw this host server error below.  What that means is your host is using something additional on your host server for security protection, which is causing all of the problems.  The javascript problem is back now even though you still have the AddType htaccess code in your Root htaccess file, which means whatever additional host server security protection your host is using is now not allowing you to fix the problem any longer.  The server is now negating your fix.  So at this point there is no point in trying to do anything at your website level.  You need to contact host support, send them server error message below and also send them the AddType fix you used which is no longer working so that you can get some real answers from your host instead of being blown off again by them.

    Access denied by security policy
    Your request is blocked by a security policy rule.

    Please contact the support team, and inform them of the time the error occurred, and anything you might have done that may have caused the error.

    More information about this error may be available in the server error log.
    Please provide the following information to our support team: | | 13.03.2017 20:03:59

Viewing 15 posts - 16 through 30 (of 34 total)
  • You must be logged in to reply to this topic.