The Gatsby Security Advantage
As Drupal experts we are very knowledgeable about the Content Management System (CMS), having worked with this open-source platform for many years. As a CMS it’s easy to use, it's flexible for developers, and it has a huge community that helps out in various ways.
Drupal also has a security team that makes public announcements and works with developers to make sure everything is secure. These updates come out weekly and you will want to stay on top of them to keep your website secure, have the latest features, and remove any known bugs so that you reduce problems when upgrading from one version to the next.
The issue with this is that once the information is public everyone is aware of it and in some cases you will need to act fast to secure your website. At Amazee Labs, staying on top of updates and ensuring that sites remain healthy and secure would all form part of our Web Maintenance service. But over and above this, is there a way to ease the pressure from updates and reduce the risk of a site being hacked?
Over the last few years, decoupled or headless websites have become more popular, the idea behind them is simple. Use a CMS like Drupal for just content editing, then expose all the content you need using various APIs such as GraphQL or JSON. This content can then be ingested into a separate frontend framework such as React or Vue.js.
Making a website this way has its benefits:
- Separate backend and frontend teams
- Not limited to a CMS or frontend framework
- Added security as CMS can be isolated
- Improved site load times
- Better testing
There are some drawbacks to this approach however, it makes things a bit more complex which requires more time spent working on it. Also, content is grabbed directly from the CMS, so as traffic builds the backend has to handle more requests and with many requests at once load times can increase.
The Gatsby Advantage
Gatsby takes the decoupled/headless approach to the next level, instead of reading directly from the CMS, the site goes through a build process, during which the data is read from the CMS and then compiled into static HTML. This means when someone visits your site, requests are all for static HTML, no processing backend logic and no waiting for database queries to complete.
The speed improvements alone make this a much better process for the end user, but it also improves security.
As everything is compiled before being exposed to the web, you automatically get a layer of obscurity from the CMS. So even if your CMS is vulnerable, bad actors simply cannot find the CMS, as opposed to knowing that “/user/login” is the default login page for Drupal.
Another great benefit when using Gatsby is that hosting usually takes place on a content delivery network (CDN), which provides many features but one of the biggest for security is DDoS protection. This should mean that even if your site is being hit with a lot of malicious requests it will remain online.
What To Watch Out For
Having said all that, even with the features listed above, there are still a few things you should watch out for when building a Gatsby or any decoupled website for that matter:
- Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
Cross-Site Scripting (XSS)
This type of attack relies on you wanting to render HTML on a page from a content editor - WYSIWYG. To include text that is bold or italic text. The downside is that if not checked correctly it can also allow someone to add a script tag to turn it into something malicious.
The good news is that if you’re using JSX the above will automatically be converted to a string, however so would your other content formatting choices.
This is where dangerouslySetInnerHTML comes in handy, as it allows the rendering of HTML and bypasses converting anything to string, but if you use this it is strongly recommended to first parse your content to remove anything that can be used maliciously, with a plugin such as html-react-parser.
Cross-Site Request Forgery (CSRF)
This attack can happen in places where the frontend needs to communicate with the backend, for example saving a webform or posting a comment. The security issue occurs when anyone can submit a form without it being possible to identify who sent the request.
Take this simple webform:
<form action="/webform/contact" method="POST"> <input type="text" name="name" /> <input type="text" name="message" /> <input type="submit" /> </form>`
Anyone that has inspected your website code can see that you can send data directly to “/webform/contact” and it will save the information - which may trigger emails. They could even put it on their own website and allow others to send you information.
However, there is a solution to this problem, a CSRF Token. This is a random string that is tied to a user and must be sent with every POST action. When a form is submitted, the sent token will be compared with the one expected and only continue if it matches.
<form action="/webform/contact" method="POST" <input type="text" name="name" /> <input type="text" name="message" /> <input type="hidden" name="token" value=”4c3f5adc0df5cddc7c19fb1005191154a880a7f8” /> <input type="submit" /> </form>
Nobody should ever claim their website is unhackable, that’s just testing your luck, but with Gatsby, you can relax a little, especially if you only have content – no user login or dynamic interactions. You should still try to keep on top of updates, and follow best practices, but overall Gatsby can just give you more breathing room to respond, simply due to the way it works.
For us, Gatsby and decoupled web development are one of the best ways to future-proof your site and keep it secure. If you want to find out more or need help figuring out what’s next for your website, we can help – let’s talk.