Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

02:00 PM
Ido Safruti
Ido Safruti
Connect Directly
E-Mail vvv

Digital Transformation Risks in Front-end Code

Why making every front-end developer a DevSecOps expert will lead to a more holistic approach to web and native application security.

One important, often overlooked, area for empowering developers with security tools and capabilities is front-end code. Front-end code is mostly JavaScript and HTML. It is the closest to the user and runs on their browser or inside their hybrid mobile applications. Companies are constantly changing their front-end code because websites and applications require frequent refreshes. There is also a high volume of vulnerabilities and security issues reported on front-end code, in part because it is easier to access and attempt to penetrate front-end code.

Digital transformation is tightly tied to the front end, the accessible face of every business in the modern era. Surveys of developers demonstrate widespread popularity of front-end coding languages. In the 2019 StackOverflow developers' survey, 69.7% of professional developer respondents listed JavaScript as their most commonly used programming language. Right behind in second place was HTML/CSS with 63.1%. According to the HTTP Archive, the number of JavaScript kilobytes requested per page loaded has increased over the past decade by 408% for desktop devices and 689% for mobile devices. This clearly demonstrates the growing reliance of web applications on JavaScript. 

Increasingly, front-end code relies on third-party code components provided by vendors and open source projects. This code does not sit in the application. Rather, it is fetched and loaded dynamically by the browser. Using third-party code makes sense in a lot of ways. It allows developers to leverage existing code that is useful, saving them development time.

Unfortunately, some of the most serious cybersecurity attacks target front-end code. Magecart attacks, for example, are executed when malicious hackers inject unauthorized front-end code into an application or modify the application's front-end code. This injected modified code, called a skimmer, collects users' financial information when they try to make a purchase. Magecart attackers abuse vulnerabilities in third-party vendors used by the application or first-party code written by your own developers that allow code modifications and the insertion of skimmers. These attacks often inject minor code modifications, which make them hard to spot with basic code reviews.

How DevSecOps Can Protect Front-end Code
Understanding the intent of code you do not control and can't see is challenging. This is the primary problem of policing third-party libraries for security risks. To tackle these, you need to adapt a two-pronged approach. You need to enable early detection of risks and vulnerabilities during integration time, but you also need to maintain the safety net of a runtime detection engine that monitors live scripts as they run on actual users' browsers and detects unauthorized changes.

To allow developers to test these libraries far earlier, we need to add tools to CI/CD pipelines that can peer inside the library code and validate the code has not been altered to carry malicious payloads like Magecart. At the same time, we need to run user-testing and client-testing of applications as they are being built. More granular testing of how applications should behave in the browser earlier in the process will allow developers to establish a baseline of "known and acceptable app behaviors."

This baseline can then be compared against how code and applications are behaving in production. In fact, security teams can run automated systems that perform deep analysis of thousands of factors identifying behavior deviations from the baseline. Deviations might be caused by new libraries or code that were not added through the standard CI/CD and automated code review process or behavior changes by third-party vendors and libraries. Changes in third-party code may be planned by the vendor due to updates and enhancements. However, these changes may have happened or, in other cases, may be due to an attacker managing to inject malicious code.

Lastly, deviations from baseline might result from changes to your own code that was modified without authorization by hackers, disgruntled employees, or well-meaning employees trying to fix something and bypassing the code and security processes to speed up their work.

This type of baseline testing would identify Magecart attacks very quickly and before they do significant damage. The testing will only work well, however, if developers make recording application behavior prior to deployment a regular part of their work practice. That's really the key - making sure that for developers' front-end security is not tedious and adds minimal work.

How This Might Work in Practice
The good news? Adding security checks and validations to CI/CD pipeline tools and platforms is straightforward, more like adding a new type of quality assurance to the existing suite of tests. Doing this does not take the developers out of their existing workflows, so it has little impact on their productivity. It also does not require additional hours or workers on the information security team.

Here's how the process might flow.

  1. A developer checks their latest code into their version control system (like GitHub). Before the new code is integrated into the main branch of the application code, the new code will be automatically built and tested with a set of security checks.
  2. If a security flaw is detected in the code or any of the libraries or third-party modules that the code is using, then the version control system automatically flags the specific lines of code under question and generates a ticket to the developer calling for additional quality assurance along with suggested remediation steps.
  3. The developer sees the ticket in their normal ticket queue and makes the fixes.
  4. The code is then run through the test suites again. It will be merged into the main branch of code if all tests pass and then deployed into production.
  5. The updated application runs in a staging environment for analysis to create a baseline of accepted behaviors that can be checked in an automated fashion against actual live behaviors.

Making every front-end developer a DevSecOps expert creates a far more holistic approach to web application and native application security. This approach is more proactive and preventative - and a lot less expensive and time-consuming over the long haul. Adopting a DevSecOps approach is only one part of a broad and inevitable transition for all developers toward assuming more responsibility for application security - and creating a world where security starts with the code.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "The Entertainment Biz Is Changing, But the Cybersecurity Script Is One We've Read Before."

Ido Safruti is a co-founder and CTO at PerimeterX, provider of application security solutions that keep businesses safe in the digital world, detecting risks to web and mobile applications and proactively managing them. Previously, Ido headed a product group in Akamai focused ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel function where a lack of checks allows the exploitation of an integer overflow on the size parameter of the tz_map_shared_mem function.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel�s tz_handle_trusted_app_smc function where a lack of integer overflow checks on the req_off and param_ofs variables leads to memory corruption of critical kernel structures.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel where an integer overflow in the tz_map_shared_mem function can bypass boundary checks, which might lead to denial of service.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in TSEC TA which deserializes the incoming messages even though the TSEC TA does not expose any command. This vulnerability might allow an attacker to exploit the deserializer to impact code execution, causing information disclosure.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in all TAs whose deserializer does not reject messages with multiple occurrences of the same parameter. The deserialization of untrusted data might allow an attacker to exploit the deserializer to impact code execution.