Anyone who has been in the web development sphere for the past few years knows that many developers, companies, and web development agencies have shifted to single-page applications. With web development options like Vue, React, and the RESTful API, developers can create fast web applications that run anywhere. Behind the front end, many of us see several APIs that help these apps retrieve or exchange data with other applications and services. The heavy reliance on APIs means they have a significant security implication, especially in preventing injection attacks, including cross-site scripting.
What Has Changed?
Shifting boundaries, web development trends, and changing responsibilities mean many people expect user input to be sanitized elsewhere, typically the server. However, this can leave applications vulnerable to different types of attacks.
What has changed is that developers no longer create monolithic web applications. What they create now are sophisticated, multi-layered web applications with a separation of the backend and the front end.
In the past, when many websites were static applications, these software solutions were sufficiently usable and interactive if they had forms that users could use to send data to the server for processing. We have come a long way since then, with what we perceive as making websites and web applications interactive changing dramatically over the years.
Dynamic websites that mainly ran and generated pages on the server had severe limitations and could not provide what we now expect of websites. While possible, it was more challenging to deliver the smooth animations, inputs with instant responses, and features like auto-complete and auto-search that we have come to expect.
With each page generated once a visitor or user sent a request, it was also much slower to open preloaded pages, which is why websites built like this seem slow in the modern age.
Additionally, without a clear separation of the front and back end, it was a lot more challenging for several people to be working on different parts of the same website or application. Changing one part of the application would affect the rest of it because of how tightly coupled everything was.
A Separation of the Front and Back End and the Role of APIs
Single-page applications (SPAs) and the frameworks developers use to create them, including Vue and React, sought to solve many of these challenges by separating the front and back end. The applications built on these technologies run in the user’s browser (client) with no need for server-side processing. In short, one can run them like static web pages.
When they need to communicate with the backend, developers use application programming interfaces (APIs) that make this possible. This approach has several advantages over how things were done in the past.
The main one is that developers could work on the front or back end without waiting for the other team to finish their end. The only requirement is that teams on either end communicate with each other on the types and structures of data they want to receive and send. They can then test each part of the website or application independently and tie everything together using APIs.
While massively advantageous and convenient, this approach comes with major security implications. The burden of sanitizing all input to prevent different types of attacks is no longer just the responsibility of backend developers; front-end developers are also having to think about preventing such attacks.
While you need to sanitize any data you send to the backend, there is no need to do so when sending data from the backend to the frontend. The reason is that this data often has a Content-type of application/json and is JSON encoded. In APIs designed correctly, both of these will not allow this data to be rendered as HTML. However, you can still display this data as part of a page.
Creativity Introduces Security Issues
Web and software development are creative and problem-solving endeavors. In some cases, although not as many as in the past because framework developers have solved many of these issues for developers, a developer needs to solve a specific, nuanced problem. They might not know the framework as well as they should or find that it lacks a feature they need to solve this issue. This is when they get creative.
Creativity is encouraged and even valued in web and software development because it is what often enables developers to come up with solutions to nagging issues. However, it is not a good thing when it comes to preventing cross-site scripting vulnerabilities.
For example, a developer might create a solution that, while creative in its creation, gives users control over the properties of an element. Depending on the data structure and types the element handles, they might have just created an XSS vulnerability.
While sticking to coding standards is always best, developers can also look at other solutions to prevent these types of attacks. For example, having Web Application and API Protection (WAAP) that secures all API endpoints can eliminate these vulnerabilities and solve other issues like preventing data loss.
More Frontend Framework Use Means More XSS Opportunities
Front-end frameworks that have been around for a long time, like Vue and React, have solved many of the issues that lead to XSS vulnerabilities unless developers decide to deviate from how they should use them.
Even when used properly, they still present security issues with their separation of the front and back. Say a developer wants to use the same backend for a mobile app and website. While possible, they now have two platforms they need to be concerned about, and the reality is that they may not be able to work on both adequately to ensure few to no security vulnerabilities.
There are numerous excellent reasons for separating the front and back end and for the use of APIs to tie them together. However, developers must be aware of how doing this introduces security issues. Front-end developers must also understand that some of the responsibility of preventing cross-site scripting attacks falls on them and not just the backend developers.
