What web server you use? If use nginx, you can try this to secure your wp-admin : location ~ ^/(wp-login\.php$) { root /var/www/wordpress/; allow 127.0.0.1; allow Your-ip-address; allow Your-second-ip-address; deny all; Other way to secure your wp-admin from brute force attacks is to add this lines to your nginx.conf : Limit Request limit_req_status 403; limit_req_zone … Read more
If you can use google authentication to connect as admin, then accessing published site pages are no different than connecting to a different user role. Make a new user role (say subscriber) and make your pages accessible to that particular role based users only. Make sure they don’t have access to anything else than these … Read more
No, not in the way you’re thinking Protect our wordpress site from security fail scanner (ex: wpscsan)? You can do this by fixing security fails, which almost universally means keep your install up to date. After all, you test for the presence of an exploit by using that exploit, so there’s no way to be … Read more
I have the feeling that either those files don’t exist or the location of the file has changed. Go into /plugins/wp-greet-box/js/ and see if you can locate the functions.js and the jquery.js. If the files are not there then they must have been deleted and that is why it’s throwing the 404 (Not found). EDIT: … Read more
No, it is not safe as it means that any security breach might end up in your code being changed. Alternatives: There is nothing wrong in using SFTP to upload changed plugins. If it is something that might take long time, you can manually put wordpress into maintenance mode by adding a file named .maintenance … Read more
See documentation here but don’t miss the note 2 and the following points : AJAX on the front-end is more complicated, ajaxurl is not defined so you have to call it with wp_localize_script(). you have to use wp_ajax_nopriv_{action} for non logged in users there could be security issue !!! About the third point : Be … Read more
When dealing with submit forms, even if they are sent with AJAX, you must play by the Never trust user’s input rule. Every data-attribute can be changed, edited via Inspector. Your only trusted validation should be on the server side, as you did with: if ( isset($_POST[‘author_id’]) || is_numeric($_POST[‘author_id’]) ) Personally, I would inverse the … Read more
Logic #1 is checking the returned value of the preg_match function with respect to 0 and with operator ===. That means the returned value of the preg_match function has to be (int) 0 or (string) 0. And after that it is checking if $_REQUEST[‘author’] is empty or not. And in Logic #2 is checking the … Read more
The reason you escape attributes is to make sure that the values don’t have any characters that will break the HTML of the element. For example, if you didn’t escape: $attr=”foo”> <script>alert(“Bad!”);</script>”; Then this: <div class=”<?php echo $attr; ?>”></div> Would output: <div class=”foo”> <script>alert(“Bad!”);</script>”</div> Which would let the script run. So wp_kses_post() is completely wrong … Read more
Blame brings us to #12101, where @westi said this: We also need to hilight that functions should check the capability as well and we ask for it to enforce visibility. The commit, [12914], was part of 3.0. I thought that maybe the restriction on loading the function at all was only added later, but it … Read more