Justin Boyer
“Times and conditions change so rapidly that we must keep our aim constantly focused on the future.” -- Walt Disney
New technologies are revolutionizing software development, but they potentially come with their own vulnerabilities. Is modern application development leaving you open to attack?
New technologies and techniques such as GraphQL promise outstanding benefits for developers and organizations. But these improvements come with a potentially devastating price to pay: it’s not always clear how to secure them, nor what vulnerabilities they may introduce.
If organizations are slow to learn the differences between new and old technologies from a security perspective, they’ll be left open to attack.
Let’s look at how modern application development has changed the security and threat landscape and how companies can overcome these challenges.
Fearmongering isn’t our style, but it’s dangerous to ignore the reality of the cyberworld. Hackers have found the new oil: data. And they’ll go to great lengths to take it from those who have it.
The University of Maryland conducted a study in 2017 to quantify the rate of hacker attacks on computers with Internet access. They found that a hacker attacks every 39 seconds on average.
That means modern applications consisting of microservices exposed to the outside world will get probed and attacked continuously by malicious actors after that valuable data within
These attacks aren’t always against large businesses. 43% of attacks target small businesses, and 64% are web-based attacks. A data breach’s global average cost is $3.9 million, a crippling sum for many small businesses.
The most devastating statistic may be this: it typically takes about six months for companies to discover a data breach. How much damage could an attacker do with six months of free play time in your network?
There is another imperative forcing companies to step up data security. Data privacy legislation has increased in response to growing concerns from consumers.
The EU’s Global Data Protection Regulation (GDPR) fundamentally changed how companies handle customer data. 88% of companies spent more than $1 million preparing to implement the rule.
The GDPR did more than increase data-protection requirements. Legislators saw for the first time the possibilities of holding companies accountable for how they use, handle, and protect customer data.
This game-changing regulation has led to several federal and state laws in the United States with similar goals.
Federal laws that impact the collection and storage of consumer data include:
Many states have also issued regulations that govern the use of their residents’ personal information:
You can find out more about these and other regulations in this article.
The trend is clear. Companies must take better care of their customers’ information or face consequences that can ruin their brand, destroy customer loyalty, and lead to enormous fines and other legal penalties .
Web application security practices have changed along with application architecture. The OWASP Top 10, has been the go-to list of security vulnerabilities for some time. However, this list isn’t as applicable to modern API-based applications.
As development frameworks have grown over time, many have added protections against the most common vulnerabilities out of the box. Because of this, the proper configuration of development frameworks mitigates and eliminates many OWASP Top 10 vulnerabilities.
The table below lists some of the traditional vulnerabilities web developers expect and why modern API-based applications mitigate them automatically.
Cloud-native architectures are a different way of building applications. Much of security is context, and the context completely changes in a cloud-first environment.
Development frameworks provide many features out of the box, such as object-relational mapping (ORM) and cross-site request forgery (CSRF) protection. And the use of OAuth and OpenID Connect for identity and authorization between microservices eliminates the need to use cookies for authentication. Without authorization cookies, CSRF isn’t possible.
In other cases, the environment takes care of many issues, such as cloud-based storage. The use of JSON eliminates attacks that exploit XML interpreters. And clients are responsible for XSS mitigation, so if you’re only exposing APIs, you don’t have to handle XSS vulnerabilities.
Does this mean API developers can breathe easy because all of their security concerns are gone? .
Changing the context changes the attack vectors and vulnerabilities. The “old” vulnerabilities make way for new threats that developers have to learn how to mitigate.
Let’s explore some API-unique vulnerabilities.
APIs and microservices provide unprecedented flexibility and speed of development. They fundamentally change the way companies react to customer feedback and build excellent solutions for their customers’ needs.
However, new technologies used to build APIs also give rise to new threats. For example, a set of APIs that each expose a small part of the business logic could make it easier for attackers to figure out your backend logic. They can watch network connections and see the URLs the client is calling and in what sequence.
APIs are also predictable. Most follow Representational State Transfer architecture or some variation of it. Because of this, common patterns develop, and attackers know how to exploit them. An API with the URI /api/users/{id} is searching for a user with the specified identifier. An attacker could deduce that a call to /api/admin would lead them to the admin interface.
Authorization is the most daunting challenge facing API developers. Monolithic applications log the user in once, store authorization information in the session, and never think about it again.
APIs are loosely coupled, platform-agnostic, and built to be lightweight. Traditional security solutions don’t work. Ensuring we know who is calling and what they can do is challenging.
We’ll delve into specific solutions to these problems in another post, but here are some ways to implement authentication and authorization between APIs.
Core technologies
Frameworks to help manage API security
In a word, no. Web Application Firewalls (WAFs) aren’t enough to protect distributed architectures and microservices.
While WAFs make attacks more difficult and provide an extra layer of security against common threats, they still focus on the network’s perimeter. The “protect the borders” mentality isn't enough to secure APIs.
Malicious actors try to mingle attacks with legitimate business transactions. WAFs have trouble detecting attacks that look like typical service traffic.
Don’t ignore the perimeter of your network, but more is needed to protect your APIs from attack completely.
Application development is undergoing a renaissance. Towering monoliths and slow delivery cycles have given way to agile microservices and daily production releases.
Along with these changes come new threats and new mitigation strategies. In our next series of articles, we’ll take a more in-depth look into the specific technologies and techniques required to secure microservices. We’ll also explain how Traceable AI fits into your security architecture.
Traceable helps companies secure their applications and APIs by providing complete visibility and risk assessment of APIs, their data flow, and transactions, and detecting and blocking attacks before they happen. Traceable does this with extremely low false positives by combining distributed tracing and cutting edge continuous unsupervised machine learning to rapidly identify anomalies in user and system behaviors. To learn more about Traceable you can visit us at https://traceable.ai or view a recorded demo.
Recommended reads.
SecOps keeps production environments safe. Now, “shifting left” approaches are needed to secure production applications and APIs.
SecOps keeps production environments safe. Now, “shifting left” approaches are needed to secure production applications and APIs.
What if we could reduce the time to detect a cyber attack all the way down to zero?
What if we could reduce the time to detect a cyber attack all the way down to zero?
M6 and M7 bring GraphQL and gRPC, new agent support, OpenTelemetry compatibility, business risk visibility and API risk scoring, many new and configurable blocking rules, lots of new discovered data on your API endpoints, and improved enterprise readiness.
M6 and M7 bring GraphQL and gRPC, new agent support, OpenTelemetry compatibility, business risk visibility and API risk scoring, many new and configurable blocking rules, lots of new discovered data on your API endpoints, and improved enterprise readiness.
