7 Security Tips for Apigee Developer Portal

A while back I have been doing some penetration testing on Apigee’s Developer portal which is based on Drupal. Drupal is a great CMS and provides you with a lot of functionality and features. For some security measures which may be ignored considering it a blogging platform or content publishing platform.
But APIs are a different type of content and the security of them should be paramount as it may lead to leaks in systems and resulting in a major break down/ takeover of the systems. You can imagine the worst that could happen!
These are some major issues I found with respect to Drupal/Apigee Dev portal.
  1. User enumeration
There are different two ways which I found are still vulnerable to User Enumeration issue.
    1. Users Profile URL
By using the URL patterns https://devportal.com/users/admin you can check if the user is present in Drupal’s database or not.
If the user exists in this case, then you will receive a message with 403 responses as below:
"Access denied. You are not authorized to access this page."
If the user does not exist, then the message will be a 404 response with the message:
"Page not found. The requested page "/users/admine" could not be found."


To keep usernames hidden from the public you can use module “Real Name”. This module allows creating a display name from any attributes of the User object in Drupal. This module will replace all the usernames in comments and Nodes to the real name.
    1. Reset password
Using password reset options on you can raise a request to change the password. Or optionally to script it you can use the below URL in curl commands.
POST http://devportal.com/user/password
If the user is available in system response will be:
“Further instructions have been sent to your e-mail address.”
“Sorry, admin1 is not recognized as a user name or an e-mail address.”
“User Enumeration Prevention” available in Drupal community for this which sets the response to always a success message even if the user is available or not. This ensures that users available in systems are not revealed to the attacker.
  1. Directory Listings of Apache and Drupal
Make sure that all your directories are protected and are accessible only to the webserver. Optionally you can create a separate user for your web server.
To protect listing of directories you can use .htaccess file at the root of your webserver.
Add this to your .htaccess file if not already there and restart your server.
Options -Indexes
Even after adding this I was able to access “/icons” and “/icons/small” paths on my installation. Well if you check your directories on the web server you’ll not find these directories in /var/www/html or whatever your hosting root directory is.
These are aliases created by apache server.
Comment "Alias /icons/ "/usr/share/httpd/icons/" from file /etc/httpd/conf.d/autoindex.conf.
And restart the web server.

  1. Information Disclosure by Install Scripts and Update Scripts
In most of the Drupal installations it is recommended to rename or delete the install.php and update.php files as they pose a security threat of information disclosure.
Optionally you can control access to these files by .htaccess. Add below lines as per your requirement.
<Files "install.php">
   Require all denied

  1. Information Disclosure by Response Headers
Drupal and web servers add additional headers to responses revealing the details about web server name, versions, PHP versions, and Drupal version.
Disabling “Server” Header:
Add below lines to your .htaccess or httpd.conf file of apache server and restart the server.
ServerSignature Off
ServerTokens Prod

Disabling “X-Generator” Header:
Add below lines to your .htaccess file. There are other ways to disable this by making some code changes in drupal core. But I am abstaining from changing any code in the core as it may be overwritten by updates.
Header always unset "X-Generator"
Header unset "X-Generator"

Disabling “X-Powered-By” Header:
This can be done by above method of unset “Header” but the expose_php flag in PHP.ini file that controls the exposure of php details to the public. Set this to “Off” and this header will not be sent in responses.

  1. TRACE Method enabled on Server
In most of the apache installation, this method is available for troubleshooting and debugging. But this exposes a great deal of information to the external public of any business logic related headers and query params.
Disabling TRACE method:
Set TraceEnable directive to “Off” in httpd.conf file of apache.

  1. Outdated versions of jQuery
There have been some vulnerabilities reported concerning jQuery versions 1.4.x. Please refer below links for more details:
These two vulnerabilities are affecting all versions prior 1.6.3 (between * and 1.6.3) and all versions prior 1.9.0b1 (between * and 1.9.0b1).
Use the “jQuery Update” module available in the Drupal community for updating your jQuery library version.

  1. PHP Easter eggs
Check if your website which is hosted on PHP is secure for these URLs:
PHP has some Easter Eggs which can be accessed. In above URL the empty query param with the code represents an Easter Egg. There are various such codes available to get information related to PHP.
To disable this set “expose_php” to “Off” in PHP.ini file on your web server.

These are my findings if you have any more then please share in comments.


Popular Posts