The 'A-B-C' of effective application security
Software applications have been a key tool for businesses for decades, but the way they are designed and operated has changed during the past few years.
Rather than running on servers within a datacentre, they are increasingly located on cloud platforms and accessed via the internet. While this has significantly improved functionality, it has big consequences for IT security.
Applications that are exposed to the internet have become a favoured target for cybercriminals. They recognise that a successful breach could provide access to a target organisation's wider infrastructure.
The problem has become even more acute as a result of pandemic disruptions. Many organisations were forced to quickly make more applications available via the internet so that remote workers could continue their roles.
Unfortunately, sufficient priority was not given to security, and in many cases, applications are now vulnerable to attack. Techniques being used include SQL injection, cross-site scripting, and command injection.
To improve this situation, organisations must focus on the 'A-B-C' of software security:
'A' is for API security
For many years, APIs were used primarily in the backend of business applications, performing machine-to-machine communication. Today, however, APIs are everywhere, and they enable most of the applications used in daily life. They are the core of businesses, powering modern digital platforms and enabling digital transformation.
Many businesses have turned to developing applications with an 'API first' strategy, allowing them to innovate and go to market more quickly. APIs enable fast delivery when used with agile and DevOps practices, allowing developers to quickly build and release new functionalities for web and mobile applications.
When it comes to security, the growth of APIs and their direct access to critical data has made them a prime target for attackers. APIs are built for automation, which makes finding and exploiting insecure ones potentially very lucrative.
For these reasons, API security needs to be high on the priority list for all security teams. They should check all APIs being used and ensure they are appropriately secured.
'B' is for bot protection
In recent years, automated bot traffic has grown rapidly. Once used primarily by search engines, bots now have a variety of uses — both good and bad.
Examples of 'good' bots include search engine crawlers, social network bots, aggregator crawlers, and monitoring bots. These bots obey the website owner's rules as specified in the robots.txt file, publish methods of validating them as who they say they are, and work to avoid overwhelming the websites and applications they visit.
Meanwhile, 'bad' bots are built to perform various malicious activities. They range from basic scrapers that try to get some data off an application (and are easily blocked) to advanced persistent bots that evade detection as much as possible.
These types of bots attempt attacks such as web and price scraping, inventory hoarding, account takeover attacks, and distributed denial of service (DDoS) attacks. They make up a significant part of website traffic today, and detecting and blocking them is critical to businesses.
These days, bots are highly sophisticated and can be almost human in their behaviour to bypass most defences. Standard methods of blocking them, such as Google reCAPTCHA, don't work as they are often better at recognising images than humans.
For this reason, IT teams need to put in place additional security measures designed to spot and neutralise bots. This is an ongoing task as the nature and capability of bots will continue to evolve.
'C' is for client-side protection
During the past few years, many novel, web-specific vulnerabilities have emerged. They include clickjacking and cross-site scripting (XSS), and many manifest themselves on the client-side of an IT infrastructure.
These vulnerabilities are causing problems because applications have shifted to being more exposed to the internet. This change has happened on the server-side and the client-side in web browsers.
This is a concern because much of the client-side logic is implemented using either open source or other third-party code, and security tends to be a low priority. This is an accepted approach in web development because the alternative is unthinkable: reinventing thousands of lines of code.
The issue, therefore, becomes one of trust. A script that is good today may be hacked tomorrow. Attackers target the sources hosting third-party code because their hack will transform every application using that code into a potential victim.
For this reason, security teams need to carefully review all client-side code that is being used and ensure it does not contain any vulnerabilities. Failure to do this could result in a serious breach.
By being aware of the 'A-B-C' of application security, organisations can make themselves much more resilient to cyberattacks. The benefits of open, internet-connected applications can be enjoyed without potential associated problems.
