Why frontend security requires your attention

This blog is written by Christiaan Bakker, Frontend Developer at Triple.

After attending Zoë Rose’s talk ‘Hear no Evil, See no Evil, Code no Evil’ about the role of developers in security at the Full Stack Europe conference in October 2022, I started to apply this to myself. Indeed, as a front-end developer I often assumed that security is the responsibility of the backend and TechOps, but is it really? In this blog, we will discuss the actions you can take as a front-end developer to support software security.

Frontend security risks and how to handle them

As a front-end developer, there are several risks that need to be taken into consideration when developing an application. Below, I will go over some of the most common risks and give some guidance on how to minimize them.

Cross Site Scripting

XSS or Cross Site Scripting is one of the most infamous forms of attacks on applications. It inserts malicious scripts into applications, making it possible, for example, to intercept users’ entered data and add malignant functionalities such as Trojans to pages.

Fortunately, frameworks like React and Angular already have built-in prevention to prevent XSS attacks. For instance, all user input and values placed in the DOM are auto-escaped, causing <script> tags to be ignored and rendered as strings. If HTML must be written directly anyway, it is important that the HTML is sanitized, for example with the packages sanitize-HTML and DOMPurify.

Cross site request forgery

CSRF is an application security attack in which a browser is tricked into performing an undesired action in an application in which a user is already logged in. As an example, a user is logged into a site. The attacker then uses this session data to identify on a different page, enabling them to send out requests on behalf of the user. This allows the attacker to reset passwords or delete accounts, for example.

One way to prevent CSRF attacks is by using CSRF tokens. CSRF tokens are related pairs of tokens given to users to validate their requests and prevent attackers from submitting requests on behalf of another user. A front-end package that simplifies implementation is csurf, a middleware that creates and adds tokens to all requests to validate that they were submitted by a legitimate user.

Third party libraries

Third-party libraries are widely used when building applications . Examples include date and time tools, 3D graphics and animation libraries. These libraries are extremely convenient for developers, as they do not have to reinvent the wheel every time.

However, this ease of use also creates risks. As the third-party libraries are not written by the in-house development team, they entail 3 primary risks:

• The lack of control over changes to the client application

• The execution of unpredictable code on client systems

• Leaking of sensitive data to 3rd parties

An example is the developer “wozheqirsplu” who had published an npm library to help developers see hardware specifications. They decided to make some money out of it by adding a cryptominer (link). This is certainly not desired by users because they unknowingly run their hardware for someone else’s profit

There are several ways in which developers can mitigate these risks. For example, where possible, it is wise to create your own hook or utility to solve a problem. Should it still be necessary to use a third-party library, tools like Retire.js and the OWASP dependency check can help to detect vulnerabilities of package versions.

The risks are not only in the code

Many of the security breaches (82% according to Verizon) do not lie within the tools employees use or the code that is written, but in the influence of a malicious person using social engineering.

At Triple, we have a security policy in place that is endorsed Triple-wide to prevent security breaches. Triple’s security officer is responsible for overseeing information and cyber security and for keeping employees attentive to the security policy. Some general suggestions from our policy for improving security within an organization are:

· Use a password manager for password registration

· Do not click on links in e-mails from a fake domain, e-mails with shortened URL links or a component that urges you to take action immediately (‘Log in now or we will deactivate your account’)

· Uninstall what you do not use/need

· Download official apps from the official source (For example: the CitizenM app from the Google Playstore)

Remember, it’s okay to ask questions. If something doesn’t feel right, investigate. Spending a minute calling someone, on a number you have independently of the email you’ve just received, might save the company thousands.- Zoë Rose

It’s up to you now

Now that you have a few guidelines for a more secure front-end development approach, it is time to implement them. By keeping security in mind in every step of the software lifecycle, it remains manageable and it does not evolve into a problem that needs to be solved afterwards. This practice is called Security by Design and more information can be found here.

Remember, security is not something you put in place once to think: ‘Ok, it is secure now’. It is an iterative process throughout the design process, in which you can constantly refine and improve. It is the only way you can stay ahead of people with malicious intentions, and the only way you can offer your users a safe and comfortable user XP.