Introduction

The API Connect Developer Portal is your API consumers’ public access point and source of documentation and information about your APIs. It is often internet-facing and is normally branded with your corporate logos and colours. It is therefore important to keep it secure.

The developer portal includes multiple security features, many of which are enabled by default, but they can be configured to suit your particular requirements. We occasionally get requests for a guide to hardening the Developer Portal but because most of the features below are enabled by default there really isn't such a document. Hopefully this post will help explain some of the features in use.

Two Factor Authentication

Many customers use an OIDC authentication provider with their developer portal, this is configured in API Manager catalog settings. Using an OIDC Provider allows you to configure any security requirements you want to within that OIDC login flow. For example, you could include two factor authentication (such as requiring a one-time passcode from an Authenticator app) or additional security questions as part of the register / login flow. The application (the developer portal in this case) doesn’t need to know anything about these additional requirements as they are entirely handled as part of the OIDC flow by the OIDC Provider. This is how Google, Apple, Microsoft, etc. do two factor authentication in their login flows.

Password Policy

As an extension to the above, if you have an external authentication provider such as OIDC or LDAP then you can configure a password policy in that authentication provider.

However, if using a Local User Registry then you can configure a password policy in the portal which will be enforced at registration and change password time. It is worth saying that the backend API Manager local user registry also has a minimum password policy which cannot be customised, so it is worth having the portal one match that or be stricter. If not, then the user experience can be slightly less than ideal as the backend will still prohibit the use of passwords that the published policy in the portal says should be allowed.

There are plenty of good analyses into what constitutes a good password, I’ll simply say that it is better to go for longer passwords than requiring bizarre character combinations that simply make them hard to remember.

See https://www.ibm.com/docs/en/api-connect/10.0.x?topic=security-configuring-your-site-password-policy

Perimeter

The perimeter module acts as an intrusion detection system for the portal. It will ban users who make invalid requests to the portal matching specific attack patterns. For example, attempting to use certain well known WordPress attack vectors against the portal will lead to the user being banned. As the attackers are rarely authenticated in these attacks the bans are at the IP level. This feature will only work correctly if the client’s IP address is being correctly passed through to the portal pods. If any load balancers are stripping the client IP, then this feature should be disabled as it will lead to the portal banning the load balancer itself and blocking all traffic to the portal.

Honeypot

The honeypot module is a spam protection device for forms in the portal. More information can be found here (https://www.jeffgeerling.com/blogs/jeff-geerling/introducing-honeypot-form-spam). It is an effective mechanism for preventing screen scraping bots from being able to submit forms automatically and is less intrusive to users than CAPTCHAs.
The portal administrator can configure which forms honeypot is enabled for but by default it is used on the register form, forgot password, feedback form and the forum post and comment submission forms.
The downside of the honeypot method of spam prevention is that some caching has to be disabled on the enabled forms for it to work so security has to be balanced with performance.

For more information: https://www.ibm.com/docs/en/api-connect/10.0.x?topic=security-using-honeypot-spam-protection

Flood Control

Flood control is the mechanism to temporarily block either users or IPs for too many incorrect attempts to login to an account, e.g., through use of an incorrect password. There are different configuration options per account and per IP (irrespective of which account the login attempt is for). The ban should be temporary and expire after the configured number of hours. The IP based bans will only work if your load balancer is correctly configured to pass through the client IP.

See https://www.ibm.com/docs/en/api-connect/10.0.x?topic=security-using-flood-control-login

CAPTCHA

CAPTCHAs are an attempt to prevent robots from auto-submitting forms and so distinguish between humans and robot scripts. They are intrusive and users are not a fan of them, but they are a fairly effective bot protection device. reCAPTCHA (from Google) is even more effective than the standard Drupal module but it requires signing up for a Google API key. The module for reCAPTCHA is included in the APIC developer portal so if you have such an API Key you can enable that and switch to it. Instructions are in the IBM Documentation here: https://www.ibm.com/docs/en/api-connect/10.0.x?topic=security-configuring-recaptcha.

By default, the CAPTCHA prompt will be shown to each user for each form type that it is configured for, but once they have successfully passed the prompt it will not appear again since it has done its job – it has determined that they are a human. They aren’t going to have turned into a robot during that session so there is no security benefit in prompting to do a CAPTCHA again on repeated submissions. Should you wish to prompt every time then this can be done in the CAPTCHA module settings.

By default, the CAPTCHA is set to be image based, you can increase the amount of background distortion, change the font and other settings in the CAPTCHA module settings. You can also switch it to be maths based instead so users must answer basic mathematics questions to be able to submit the form (not a popular choice, but the option is there).

For more information see https://www.ibm.com/docs/en/api-connect/10.0.x?topic=security-configuring-captcha.

Session Limit

Most websites want to limit a user to only being able to have a single concurrent session with the portal at any one time. The session limit module does this enforcement. It will allow multiple tabs (and windows) from the same browser as those are the same browser session, but it will block login attempts from other browsers/machines if the user is already logged in.

See https://www.ibm.com/docs/en/api-connect/10.0.x?topic=security-configuring-session-timeout-limit

Automated Logout

The settings within Configuration->People->Automated logout allow you to configure how long portal sessions should be allowed to remain inactive for and then force log people out after that period. If the tab is active then some JavaScript will force reload the page in order to ensure no confidential data that only authenticated users can see is left visible on their screen.

Note that these settings are not the same as session lifetime settings which are configured in API Manager (and possibly also in your OIDC provider if using one, e.g. refresh tokens), these settings are purely about inactivity and how long a session can be allowed to stay active without any interaction with the server.

See https://www.ibm.com/docs/en/api-connect/10.0.x?topic=security-configuring-session-timeout-limit

Content Security Policy

Content Security Policy is a relatively recent development and relies on the browser to honour the Content-Security-Policy header and enforce it. Up until recently there were elements of the javascript in use in Drupal that would have prevented the use of CSP enforcement (such as the ckeditor WYSIWYG editor). Those problems should now have been fixed so the latest versions of API Connect (in 2022) might now be able to do CSP enforcement. It is not officially supported yet as it needs more thorough testing, but the portal does include the Content Security Policy module that allows the configuration of that header per portal site. Care needs to be taken to allow javascript to be able to perform its normal functions, the browser will block it if not correctly configured – e.g. if you are using monetization then the Stripe checkout code needs to be able to access the Stripe servers.

IP/User Bans

As well as all the automated features above, it is also possible to manually block certain users and IP addresses. IP bans can be managed from the Configuration->People->IP address bans. Instructions can be found here: https://www.ibm.com/docs/en/api-connect/10.0.x?topic=security-managing-banned-ip-addresses

To block specific user accounts go to People in the top administration menu and then check the box for the relevant user and select “Block the selected user” from the Action menu and click Apply. That will prevent the user from being able to login. They can be unblocked in a similar fashion.

See https://www.ibm.com/docs/en/api-connect/10.0.x?topic=people-blocking-unblocking-specific-users

Restrict by IP

This functionality allows restriction certain users or roles to only being able to login from specific IP addresses or IP ranges (using CIDR notation). This should be considered an additional layer of security and like most IP based security features it is “best can do” as it may be possible to spoof the client IP.

Drupal is a single application, so this is the only mechanism to try and limit administrator access to the internal network. This functionality is obviously dependent on load balancers correctly forwarding the client IP.

For more information see https://www.ibm.com/docs/en/api-connect/10.0.x?topic=tasks-restricting-access-by-ip-address. 

HTTP Headers

It is possible to configure various security headers from the Configuration->System->Security kit page such as X-XSS-Protection, CSRF, X-Frame-Options for Clickjacking, etc.

Drupal has CSRF protection built into every form already (which cannot be disabled) for authenticated users. More information on that can be found here: https://www.drupal.org/node/2319205

Certain headers such as Strict-Transport-Security for HSTS are set by the portal webserver and cannot be customised. This is so that those headers can be added to all responses (including JavaScript, CSS and image files) whereas the configuration settings within the Security Kit module only apply to the PHP page response itself.

More information can be found here: https://www.ibm.com/docs/en/api-connect/10.0.x?topic=security-using-kit

Security.txt

A security.txt file provides a standard way for people to find out how to report security issues with your site. More details on the standard can be found at https://securitytxt.org/. This file can be enabled and configured at Configuration->System->Security.txt.

Limiting Search Engines

It is possible to configure the site robots.txt file from within the Drupal site, go to Configuration->Search and metadata->RobotsTxt.

Further configuration of the metatags used on site pages can also be configured under Configuration->Search and metadata->Metatags.

These can be used for search engine optimisation or to block access to search engines entirely.

See https://www.ibm.com/docs/en/api-connect/10.0.x?topic=tasks-restricting-preventing-access-from-search-engines

Disabling Forums & Comments

Forums and comments are a great way of creating an interactive community which can be self-helping, but it needs a certain audience size. It also requires moderation on an almost permanent basis to police and avoid anyone making inappropriate posts on your corporate branded website which the company made not want. Because of this moderation requirement some customers want to disable these features.

Comments can be disabled per content type, the instructions are in the IBM Documentation here: https://www.ibm.com/docs/en/api-connect/10.0.x?topic=tcoidp-turning-comments-specific-content-types-off-in-developer-portal

The forums can be disabled following the instructions here: https://www.ibm.com/docs/en/api-connect/10.0.x?topic=forums-turning-off-in-developer-portal

I hope this quick guide through the API Connect Developer Portal security features has been helpful, it is by no means exhaustive and there are other addon modules for additional security features available on drupal.org.
If you would like to request a specific module be included with the developer portal or have a new security requirement please do get in touch.