Today when I was working on the implementation of the Google OAuth 2.0 client to Access Google APIs, I found an interesting problem that may happen to every developer that tries to create an OAuth callback page for Google in their websites if it's hosted on a Plesk server. After some research I found this interesting issue that claimed just as I though, that there was a problem with the server when i tried to login through OAuth2 with my Google account in a very simple implementation of the Google Client, where all I had to do was to login to the app, authorize the access and then, Google should redirect me to the oauthcallback.php URL of my website. Curiously, all I found was a 403 page that shouldn't be there:
No exception from PHP as I would expect if something went wrong, just a forbidden message from my server. At the beginning I though that maybe there was a problem with the permissions of the file, but, after verifying the apache logs I found exactly the same exception as described in the Github issue that I mentioned before, it was related to a security rule of ModSecurity, which is by default available and is used on every Plesk server out there.
In this article, I will explain to you how to easily bypass this problem to make allow your application to follow the OAuth API Authentication flow as usual.
1. Open the Web Application Firewall (ModSecurity)
Open the tools and settings page of your plesk based server:
Once you access this module, you will find the application firewall fully active:
In order for your authentication callback page to work properly, you will have to add an exception to this firewall.
2. Switch off the rule that is causing the exception
The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls. The CRS aims to protect web applications from a wide range of attacks, including the OWASP Top Ten, with a minimum of false alerts. One of those rules is being a false-positive, and is basically the cause that your OAuth callback page isn't working as expected (more information about this issue here).
As next step, you need to switch off the security rule that is preventing the OAuth2 callback page from working properly. In my case, as specified in the image of this article (Access denied with code 403 (phase 2). Matched phrase ".profile" at ARGS:scope):
You can see that the triggered rule is identified by the ID 210580, so all you need to do now is to simply add the ID in the "Switch off security rules" area of the application firewall:
Then click on Apply and interact with the OAuth2 callback page of your website, it should be accesible and work again as expected. Note that depending on your case and the scope of your application, the ID of the ModSecurity rule may be different, so if you get the exception, be sure to check the logs and see the ID of the rule that is triggering the problem.
Happy coding ❤️!
