APIGEE recently announced - from May 31, 2020, Apigee-sponsored hosting for Drupal-based portals will end. The existing customers who wish to remain on Drupal 7 need to assume hosting responsibility, 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. But if Drupal has many security features and remains as one of the most secure Content Management System (CMS), what could possibly be the urgency to migrate?
What are the concerns?
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 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, most if not all were built on Drupal 7. 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 the following security challenge.
Drupal 7 Can Put your Developer Portal at Risk
While Drupal also has many security features, security is not about working in isolation. If one is to secure their digital property from the possible threats, it needs to follow best practices to maintain the top-notch standards.
One of the most important is keeping the core updated.
If you fall a long way behind the latest update, you are opening yourself to vulnerabilities. Let’s know in detail 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, 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 is a best practice to check it into a revision control system (like GIT).
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.
Should you Migrate your Developer Portal to Drupal 8?
When choosing a solution, you need to balance your customization requirements against the time and knowledge required to implement your portal. Migrating your developer portal to Drupal 8 will ensure that any investments you make will extend the security of your digital presence.
Have doubts around your API security or want to migrate to Drupal 8 developer portal? Get in touch with our experts. We provide a range of services around API designed with a strategy tailored to your success.
