Should You Migrate Your Developer Portal To Drupal 8?

Apigee recently announced that it will end its sponsored hosting for Drupal 7-based portals from May 31, 2020. The existing customers who wish to remain on Drupal 7 based developer portals need to assume hosting responsibility. Alternatively, they can either migrate to Drupal 8 or move to Apigee's integrated portal.

Those who wish to stick to Drupal 7 developer portals might possibly face challenges. While Drupal remains as one of the most secure content management system (CMS), there is still a need to actively consider migrating your dev portal to Drupal 8.

Here's why.

Drupal 7 End-of-Life is Near

The developer portal is essentially a CMS, in case of APIGEE, based on Drupal. As the backend CMS, Drupal provides a core set of features in the form of modules that make it easy for you to build the content, as well as manage websites.

Developer portals orchestrate the API ecosystem which helps developers and external partners to quickly and securely gain access to the tools and information they need to explore, test, & consume APIs.

APIGEE supports several developer portal solutions, ranging from simple turn-key to fully customizable and extensible, with most of them built on Drupal 7. However, with community focus shifting to Drupal 9 release and end-of-life approaching for Drupal 7 (November 2021), among other circumstances, APIGEE will no longer be supporting the D7 developer portals.

With APIGEE support ending in May 2020, Drupal 7 developer portals will face some serious security challenges.

Drupal 7 Can Put your Developer Portal at Risk

While Drupal has sophisticated security features, no Drupal implementation works in isolation. If you want to secure your digital property from all possible threats, you needs to follow best practices to ensure that its secure both in itself, and in its interactions with all other systems.

And one of the most important ways to do that is keeping the core updated.

If you fall way behind the latest update, you are opening yourself up to vulnerabilities. Here's a closer look at how Drupal 7 can put your developer portal at risk.

1. Doesn’t prevent cross-site scripting

Cross-site scripting (XSS) is a class of code vulnerabilities that allows code to be executed inside your browser without your consent or knowledge. XSS exploits are commonly performed with JavaScript, but Flash, Java, and other similar web programming technologies have been used.

It is one of the most frequent security vulnerabilities that a site owner should be aware of. It can be introduced in custom themes and custom-and-contributed modules. A poorly configured site can allow a malicious visitor to use XSS to change a user's password.

Out of the box, Drupal 7 isn’t very effective to identify and fix XSS vulnerabilities.

In Drupal 7, elements like Drupal variables or Ctools exportables are represented as PHP code. This use of PHP input format in the core exposes possible code execution to vulnerability.

Drupal 8, however, filters the PHP input format in the core, manages code in a revision control system like Git, and protects the code from any possible attack. Configuration Management Initiative uses YAML as the export and import format. YAML files are easy to manage together with your code and it is a best practice to check it into a revision control system.

2. Exposing session cookies

Drupal 7 stores the session ID and checks directly against the incoming session cookie from the browser. This poses a huge risk as the value from the database could populate the cookie in the browser assuming the session as well as the identity of any user who has had a valid session in the database.

On the other hand, Drupal 8 secures the session IDs against exposures via database backups or SQL injection, encourages serving your entire site via secure channel SSL and no longer strips the www from the session cookie domain.

3. No Automated CSRF token protection in route definitions

Cross-site request forgery (CSRF or XSRF) is a process where a request is made to a site which takes an action when the user did not intend to take that action.

GET requests with configuration change are not protected from CSRF in Drupal 7. This brings all the secure and unsecured requests under the scanner. However, Drupal 8 makes it easy to specify a route (or system path) require a CSRF token.

4. No Clickjacking Protection

Drupal 7 cannot protect a site from click-jacking attacks wherein forms or links on the site are presented in a disguised fashion on an attacker's site inside an iframe. It cannot block the unauthorized re-use of site content via iframes too.

However, Drupal 8 does this easily by sending the X-Frame-Options: SAMEORIGIN header in all responses by default. This header is respected by most browsers and prevents the site from being served inside an iframe on another domain.