Category: Traceable Application Security

  • Web Application Firewalls Aren’t Protecting Cloud-Native Apps

    Web Application Firewalls Aren’t Protecting Cloud-Native Apps

    Your web application firewall (WAF) is humming at the edges of your network, faithfully blocking malicious attacks before they can do any harm.

    Better yet, it’s a next-generation WAF (NG-WAF). It consists of signatures, rules, and a sprinkle of machine learning to protect your applications (and user data) from harm. You’ve got it covered, correct?

    Yeah, right.

    You’re a security expert. You don’t take anything at face value. How do you know for sure your applications are protected?

    And what if you have cloud-native applications — microservices, HTTP requests flying around, multiple touchpoints for each user request? Can an NG-WAF protect all of these apps from external and internal attacks?

    We’ve discovered the answer. Let’s take a look at what NG-WAFs do well, what they struggle with, and whether a solution makes up for their gaps.

    The Challenge of Traditional Web Application Firewalls

    According to OWASP:

    A “web application firewall (WAF)” is an application firewall for HTTP applications. It applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL Injection.

    Modern applications are more transparent than traditional web applications. Focusing on speed and agility of development — Continuous-Integration, Continuous-Delivery (CICD), and DevOps replacing the waterfall development model — developers tend to use open-source projects to save development time and cost.

    This transparency, ease of access, and incredible detail in documentation make the modern applications attractive targets. The frequent changes in applications make it almost impossible to detect and secure every vulnerability.

    WAFs have added new features over the years, but the backbone of their detection still lies in their signatures or rules. The question is: have WAFs indeed adapted to the needs of cloud-native applications?

    Applications have evolved from massive monoliths to microservices and distributed architectures. They now live virtually in any combination of public, private, or hybrid cloud. The new challenges and threats brought on by distributed architectures have given rise to the NG-WAFs.

    Network firewalls underwent a similar transition, where the Next-Generation Firewalls (NGFWs) introduced a new perspective of looking at firewall traffic with deep packet inspection and attack-centric detection models.

    The next generation WAFs have been frequently defined with three principal characteristics:

    • Detection is based on the application and the attacker’s behavior.
    • Going beyond signatures to identify anomalies and fundamental attacker actions.
    • Cloud-native deployment supporting various cloud platforms, APIs, and microservices architecture
    NG-WAF

    What NG-WAFs Solve

    NG-WAFs propose to solve the new problems introduced by changing application architectures.

    How well have they done? Let’s start by reviewing what NG-WAFs do well.

    Increased Cost to Attackers

    Attackers have a distinct advantage — they don’t play by the rules.

    We live in an age when you can connect almost any device in your home to the internet. Unfortunately, many IoT devices don’t take security measures, which means attackers are salivating at the opportunity.

    Malicious actors try to mask their origin and evade detection using an army of “bots.” Yes, they’re attacking you with DVRs, cameras, and lightbulbs.

    NG-WAFs take a fresh approach of correlating such behavior to detect the attackers and block them, thus increasing the cost for attackers and partly deter the script kiddies.

    Layered Protection: The In-depth Defense

    Defense in Depth increases system security by using a multi-layered approach with intentional redundancies. It’s commonly referred to as the “castle approach” because it mirrors a medieval castle’s layered protection. If one layer fails, another is waiting to take its place.

    NG-WAFs have evolved to protect at multiple levels, including the traditional perimeter and the newer approach of embedding alongside the applications. These layers make an attacker’s job much more difficult and expensive.

    Machine Learning and Behavioral Analytics with Automated Policy Learning

    NG-WAFs aggregate detection from multiple applications to understand attackers from a broader perspective to contextually score them. Using machine learning and behavior analytics on the aggregated data, NG-WAFs automatically disable signatures that would trigger false positives and update the application policies accordingly.

    Virtual patching

    You ideally want to identify and fix every vulnerability found in your code. But real-world business situations dictate that not all vulnerabilities will be fixed quickly or at all.

    A few NG-WAFs support virtual patching to prevent attackers from exploiting critical vulnerabilities until an official fix is available.

    Cloud-native Support

    NG-WAFs now support deployment in a public, private, or hybrid cloud. The NG-WAFs automatically integrate with a containerized approach to scale security natively and elastically. They distribute nodes all over the world to maximize coverage without increasing latency.

    What NG-WAFs Have Failed to Solve

    NG-WAFs have made strides in securing applications. They’ve used defense-in-depth to make successful attacks increasingly tricky to pull off.

    They’ve incorporated new architectures and virtual patching to match the pace and style of current app development. But they haven’t solved every problem.

    Let’s look now at what NG-WAFs are missing that may open up holes in your security.

    Motivated Attackers Can Bypass NG-WAFs

    WAFs introduce obstacles for hackers and penetration testers by making vulnerability finding and exploitation more resource-intensive. However, an experienced hacker or a researcher with enough motivation would probably be able to find ways to bypass it.

    When the application use case becomes complex, it may demand disabling many defenses that produce a higher false positive rate. The more complex a web application is, the bigger its attack surface, and the easier it is to find a bypass for it.

    NG-WAFs Are Vulnerable to Use Case Exploitation

    The same application deployed in different contexts exhibits different behavior. Requests that are harmful for one application may be perfectly normal for the other as user behavior varies for each case.

    NG-WAFs do not have a complete picture of application usage — they cannot detect the business use case. The attack patterns stay hidden within regular traffic and nested protocols. Eventually, the attacker can tune himself to the business traffic and bypass the NG-WAFs resulting in a window of vulnerability and delay in breach detection. Straightforward implementations for detecting such use case exploitation often result in a high rate of false positives and false negatives. Further, customers rarely use all of the available features and rules in modern NG-WAFs.

    Machine Learning and Behavioral Analysis Are Limited to Perimeter Defense

    NG-WAFs have evolved from WAFs and base themselves on a “perimeter defense” model — it guards only against malicious traffic originating outside the network. However, this model fails if an attack comes from within – a common occurrence given the wide variety of ways users can connect to an internal network.

    The new “stay at home” normal and increased risk of insider threats has led enterprises to adopt the Zero Trust model. It is essential to monitor the external traffic along with the internal flow and state of the applications.

    Missing Runtime Protection

    Malicious hackers are attacking all the application stack tiers, be it web, memory, or database. By design, NG-WAFs are limited at the edge of the application module and cannot protect the application at runtime. With this knowledge, the attacker could also circumvent the virtual patch defenses once the vulnerability is known to them by altering their attack method or mingling with the business traffic.

    Monitoring blind spots

    Monolithic frameworks base the visibility into the application on logging frameworks. Want to know what’s happening? Only one directory to check.

    Modern applications built on microservices and serverless introduce advantages to application development, but there’s also the cost of reduced visibility. You can monitor each service individually, but one can quickly lose sight of the global system behavior.

    A single request to the modern application can create a chain of calls behind the scenes. What appears simple can sometimes be incredibly complicated. For example, take a look at what happens inside Netflix when you hit play during your latest binge.

    This call chain generates a massive amount of data along its flow path. External applications have trouble ingesting it all. Instead of solving this problem, most NG-WAFs limit the amount of data they can capture and process, introducing blind-spots the attackers can leverage to bypass them.

    How to Protect Cloud-Native Applications

    Cloud-native microservice architectures introduce drastic benefits but are also challenging to defend. While NG-WAFs have made some strides, they still fall short in several crucial areas. To comprehensively protect your cloud-native apps you should look for a solution that seamlessly provides both security observability and intelligent threat detection. Look for solutions that offer:

    • end to end distributed tracing and visibility, increasing the accuracy and depth of attack detection without extra overhead
    • features that establish baselines for user behavior, API logic, and data flow to identify anomalies
    • the ability to block business use case abuses, insider attacks, and threat actors, even in distributed systems
    • visibility that provides a complete picture of how data (especially sensitive business and personal data) moves throughout your application so you can see problem areas before they become exploits
    • discovery and protection of the complete eco-system of your microservices

    If you’d like to learn more about TraceableAI you can view a recorded demo of Traceable in action.

  • What Runtime Application Self-Protection (RASP) Doesn’t Solve

    What Runtime Application Self-Protection (RASP) Doesn’t Solve

    RASP, or Runtime Application Self-Protection, is a modern security technology that protects web applications from attacks during runtime. The technology is an important complement to defense systems that focus on the perimeter, but RASPs also have weaknesses that can introduce their own vulnerabilities.

    What are RASP’s strengths and weaknesses in protecting against modern security threats? Are there better solutions that offer more in-depth insight into attacks as well as detect suspicious behavior?

    A deeper dive into RASP

    Gartner defines RASP as “a security technology that is built or linked into an application or application runtime environment and is capable of controlling application execution and detecting and preventing real-time attacks.” Many IT organizations already deploy them, often in conjunction with other security solutions.

    An ideal RASP promises:

    • Deeper-rooted code-level visibility into applications
    • Passive and active incident response features such as monitoring/alerting and blocking modes
    • Configurable options to log, alert, challenge, or block malicious behaviors
    • Support for many languages and execution platforms
    • Autonomous operation without manual tuning
    • Coverage for a broad set of vulnerabilities, including OWASP top 10
    • Integration with secure software development lifecycle (SSDLC) and monitoring tools.

    RASP fills the security gaps left by a perimeter defense model like Web Application Firewall (WAF), which protects both legacy and modern applications. Based on these promises, RASP may look like the necessary missing piece of your security stack. In practice, however, it has weaknesses. Let’s dive deep into RASP to understand its advantages and shortcomings.

    RASP advantages

    Watches rather than predicts

    Similar to WAF, Runtime Application Self-Protection works by blocking malicious behavior but does so without extensive need for preset rules and tuning. Rather than building a trained model or predicting behavior, RASP watches the application at runtime to see that those actions are actually performed. For example, a request call to a database occurred, a shell command is executed, or that a file is opened.

    DevOps-centric attack visibility with better SSDLC integration

    RASP provides visibility into how an application is being attacked, providing better intel and alerting security personnel and developers to the exact vulnerable code. Developers can use this information to modify the codebase and eliminate security vulnerabilities. RASPs may also offer the option to integrate directly with the application development lifecycle to pinpoint vulnerable code based on attacks observed in the production environment.

    No training required

    An ideal RASP doesn’t need to be taught what bad behavior looks like. That’s because it is tied to the application stack, so knows what the application should and shouldn’t be doing. When the application’s behavior changes, it’s no problem for RASP to adapt because the security is based on the application and not on a set of predefined rules and educated guesses.

    Provides time to fix vulnerabilities

    Programmers are responsible for developing and releasing new applications and features, and subsequently developing updates and patches as vulnerabilities and bugs are discovered. It can take organizations months to apply patches which creates a window of opportunity for hackers. Because RASP protects against incoming attacks, it provides the engineering team time to fix vulnerabilities free from the pressure of working during a crisis. It is synonymous with WAFs’ virtual patching.

    Cloud agnostic

    The RASP protection design is rooted in modern software engineering techniques such as instrumentation, dynamic hooks, and secure SDKs. It works by implanting sensors in the existing application code to monitor and control critical execution points in real time. Utilizing these techniques, RASPs become part of the application, allowing them to remain protected independent of their deployment environment. RASPs may not require network calls and work in any deployment architecture, including on-premise, cloud, and containers.

    RASP disadvantages

    Confined context

    Purely from a technical viewpoint, since RASP sits within the application framework, it may look to be a smarter alternative to perimeter defense solutions like WAF. Practically, however, no application is self-contained;  they interact with a multitude of other services and components. Consider that each application module can be deployed in different endpoints, further limiting the RASP’s visibility and capabilities.

    Use case abuse

    We frequently hear about large companies breached with modern application attacks like Broken Object Level Authentication (BOLA). Attackers substitute their resource ID in the API call with a resource’s ID belonging to another user. The lack of proper authorization checks allows attackers to access the specified resource resulting in BOLA. Since the input remains consistent with what the application received before, RASP finds no reason to inspect and will let it pass through. Attackers can abuse similar use cases like Broken Function Level Authorization (BFLA) without RASP suspecting the intrusion. Protection for such attacks requires building broader business context from the application, which RASPs lack.

    Normal API request by Robby to fetch his profile BOLA Attack: Robby changes his user id in the
    request and reaches Ava’s profile
    <code>
    REQUEST
    ===============
    GET /customer/
    12548
    /profile
    Host: shop.store
    Cookie: session=
    5015ee5d-6133-cab4874b
    Accept: application/jsonRESPONSE
    ===============
    HTTP/1.1 200 OKContent-Type: application/json{“id”:
    12548

    “fName”: “Robby”

    “lName”: “Saxton”

    “phone”: “202-555-0128”

    “ssn”: “987-65-4325”

    “address”: “3454 Crummit Lane,

    Omaha, NE

    68114”
    }

    </code>

    <code>
    REQUEST
    ===============
    GET /customer/
    12549
    /profile
    Host: shop.store
    Cookie: session=
    5015ee5d-6133-cab4874b
    Accept: application/jsonRESPONSE
    ===============
    HTTP/1.1 200 OKContent-Type: application/json{“id”:
    12549

    “fName”: “Ava”

    “lName”: “Rose”

    “phone”: “340-5556-577”

    “ssn”: “449-26-2109”

    “address”: “4702 Gordon

    Street, Chino, CA

    91710”
    }

    </code>

    Missing distributed protection

    Since RASP only has visibility for the current application context, additional application-level Distributed Denial of Service and Bot protections cannot be efficiently solved by RASP. A perimeter defense solution can completely isolate that traffic, absorb it, and take defensive action even before the attack hits the application stack.

    Intrusive deployment

    RASP requires an intrusive deployment model and is highly dependent on the platform and codebase used for the application to be beneficial. It has to be deployed along with the application in the application stack. Some organizations may not feel comfortable deploying RASP for critical services, thus needing to invest more in other security solutions that add cost and maintenance.

    Deployment challenges

    Conceptually, RASP can do more in-depth protection sitting within the application stack. But there are practical challenges in managing and updating a RASP component deployed at every endpoint. RASP adds additional performance overheads not just on the application execution but also on the dedicated effort required to deploy, tune, and monitor itself and the runtime environment. And to determine proper placement that protects all assets, RASPs may need you to gather internal information about the application and trace data flow.

    Unintended consequences

    Though RASP’s goals are noble, its deployment can create unintended consequences that produce pain points. For example, situations may require the rewriting of software execution at the last minute, introducing risk from a support/incident response perspective, particularly as applications are modularized and supported by distributed teams.

    Performance degradation and impact on service level agreements

    In today’s high-performing environments, where availability is expected to be at least four 9s, downtime could severely impact SLA’s, resulting in lost revenue and damage to the company brand. RASPs might impact the application functionality even in monitoring mode as they wrap over existing essential library functions. Since RASP does not learn the business context, it may predict that a perfectly valid use case is malicious. Allowing RASP to stop code running in production amid an attack may pave the way for an effective (and self-imposed) Denial of Service (DoS) engine.

    Too much reliance

    RASP should be considered as another layer of control, but human behavior can lead to too much reliance on RASP for application protection. This behavior can generate a pile of vulnerabilities that attackers can use in conjunction with other techniques to exploit the application. For in-house-developed proprietary libraries, RASP tools are still not substitutes. The Secure Software Development Lifecycle needs to be followed with other formal methods such as source code reviews and automated tools, like static application security testing and dynamic security application testing, to identify and remediate vulnerabilities in both the source code and the application.

    You deserve better

    RASP is not a plug-and-play technology; it requires a full cycle of validation with existing applications to ensure functionality and performance are not adversely affected. What RASP makes up for in some areas it lacks in others.

    There is a need for a better solution in the application security world that can provide more in-depth insight into attacks as well as detect anomalous behavior. Traceable provides this hybrid approach by combining distributed tracing with intelligent analytics to build a complete picture of your microservices and protect them. Don’t just cover one part of your application; defend it all.
    ‍

    If this sounds like a smart approach to detecting and treating modern security threats, then we should talk. View a demo of Traceable in action.

  • Security Risks With No-Code/Low-Code Tools

    Security Risks With No-Code/Low-Code Tools

    As the popularity of no-code and low-code tools grows, so, too, do security concerns

    The demand for new applications is growing at a rapid rate. Many individuals and business units will not tolerate delays. As a result, citizen developers are stepping in, some of whom may be sanctioned by the company while essentially operating as shadow IT.

    Common to both groups is that they increasingly are aided by the wide availability of no-code/low-code development tools and platforms on the market today. Such solutions abstract away many coding tasks, offering developers a visual studio or palette to create applications by dragging and dropping software components and smaller apps.

    No-code/low-code tools offload tedious chores from professional developers, allowing them to work more efficiently. For those without that expertise, these tools enable people who have intimate knowledge of the business create their own applications and automate processes.

    Development is not only faster but less structured. As such, these technologies in the hands of those not trained in security can introduce risk.

    There are many ways citizen developers can expose a business to cyber risks. One common issue in many companies is that citizen developers (like their professional counterparts) do not want to reinvent the wheel. If they can find an existing or open source component to an application, they might freely use it when developing an application. For example, rather than hard coding a front-end mobile user interface for different platforms, they may just take existing ones and use them for their new applications. Similarly, if they want their application to perform real-time analytics, they could use an open source events stream engine. And if they want to create an interactive chatbot, they might use open source cognitive apps. The problem is that they select these no-code/low-code apps with very little vetting of the code components they’re using.

    Another common issue is that a citizen developer might ignore built-in security features in a component that makes up their composite application. For example, they may choose not to password-protect a database to simplify its use. Or they may decide to forgo best practices and send data across public networks unencrypted.

    There are many choices like these where attention to security is needed. Yet, most citizen developers do not even know to be on the lookout for potential security weaknesses.

    Layering in Security Before, During and After Apps Are Created

    Obviously, citizen developer applications must be tracked, vetted and fixed before potential vulnerabilities are exploited by attackers.

    To do that, security needs to be integrated throughout an application’s life cycle. It is no longer enough to only test for vulnerabilities after an application is developed and let it operate unchecked forever. Additionally, security must be real-time instead of reactive. It must constantly examine the elements of an application as they operate and are modified.

    Cobbling together components using no-code/low-code techniques introduces additional issues. While the individual components may be trusted, the use of several components together might expose data or provide a weakness that can be exploited. Additionally, a composite application that is secure today may no longer be so if a new vulnerability emerges for one of the software elements within the application.

    What many organizations are finding is that they need to marry DevOps and security. Hence, the growing focus on DevSecOps in the industry. DevSecOps is increasingly necessary to find weaknesses and vulnerabilities in modern applications composed of loosely coupled components.

    The constant refreshing, updating and replacement of applications dictate that security must be an integral part of the entire life cycle of an application. Again, another reason to bring security into the application life cycle, just as DevOps does for development and deployment.

    And the complexity of applications built, even when using low-code/no-code methods, means security needs to be more sophisticated to understand hidden dependencies in today’s loosely coupled applications. Any security solution cannot be passive. Simple scanning for known vulnerabilities is not enough. A solution must understand the way components of a citizen developer application change over time and interact with one another.

    The bottom line is that cybercrime protection must be implanted at the code level, and secure coding practices must be instituted, especially when citizen developers are driving application development.

  • Web Application Security is not API Security

    Web Application Security is not API Security

    Do you follow the same procedures to secure a web application as you do an API? Is there a difference between the two?

    We’ve spoken about API security quite a bit in the past few months because we believe that there are critical differences between API security and traditional web application security. A lack of understanding of those differences is dangerous.

    Let’s look at the differences between the two and why you should treat API security differently from application security in general.

    What is API security?

    API security is the practice of defending web APIs against attacks. Building APIs, typically with microservices as the foundation, has become a growing trend. Many mobile applications and websites send and retrieve data using APIs, even if the end user is unaware of this fact.

    APIs are different from traditional web applications, and those differences can lead to critical security issues.

    What Makes APIs Different From Traditional Web Applications?

    I’ll answer that question with a picture, then proceed to “drop the mic.”

    Here’s the entire Netflix architecture, comprised of about 700+ microservices. (Source)

    (Picking the mic back up.)

    The above picture illustrates why APIs are fundamentally different from traditional web applications. What was once one request to one server has become dozens or hundreds of requests to dozens or hundreds of microservices.

    Previously, the work was relatively easy; defend one large application. Now, you have to protect hundreds of small web applications and the data they access. Authentication and authorization don’t look the same. The built-in session management of your favorite framework has gone out the window. Each microservice is its own little kingdom.

    In addition, you now have to know where all of these API endpoints reside, what version they’re running, and how to scale them when demand increases.

    Finally, changes to the development and deployment environment cause changes in how malicious actors attack applications. Are you familiar with the new ways attackers target APIs?

    What Are the Most Significant Threats Against APIs?

    The OWASP API Top 10 project outlines 10 dangerous risks with APIs. (See this post for the breakdown.)

    Instead, let’s look at the big themes the API Top 10 brings to the forefront. Then we’ll discuss some specific breaches that illustrate what happens when APIs are vulnerable.

    Authentication and Authorization Win Top Prize

    Okay, maybe “Most Likely To Get You Hacked” isn’t much of an award, but authentication and authorization are the most prolific and dangerous API security flaws.

    Authentication and authorization in APIs feel like a new world for many developers. A development framework doesn’t manage a session, but instead, applications pass JSON Web Tokens (JWT) around with claims attached.  In a nutshell, every microservice must verify the caller’s identity and permissions before performing any work on their behalf.

    As the number of APIs grows, it’s more likely that developers will miss some authorization checks, and a data breach is waiting to leap out and strike when you least expect it.

    API Endpoints Are Everywhere

    I remember taking my two-year-old daughter to Disney’s Magic Kingdom during spring break. I had to slip a kiddie leash on her to make sure she didn’t disappear in the crowd. It was challenging to keep track of only one child in that vast mass of people.

    An explosion of microservices fills your infrastructure with a crowd of endpoints, and kid leashes don’t seem to fit Docker containers very well. It’s easy for APIs to disappear.

    Unfortunately, these “shadow APIs,” whether spun up by a developer for testing purposes or just an old version left out in the wild, can become a point of attack. They may not be secure, and if you don’t know they’re still publicly exposed, someone could be attacking it without your knowledge.

    Examples of Real API Vulnerabilities

    Let’s illustrate the differences between API and web app security by looking at real vulnerabilities.

    Shopify “Collaborator” Vulnerability

    Security researcher Uzsunny found a critical flaw in the Shopify “collaborator” functionality that allowed an attacker to assign themselves the “collaborator” role on any store. This feature unlocks all sorts of administrative functionality.

    It turns out that the API endpoint that handles this collaborator business logic didn’t verify that the request to add a collaborator to a store came from the store manager. Therefore, anyone could call that endpoint with the right arguments and get admin rights to any store on the Shopify platform.

    Check out our detailed post on how this vulnerability works and why it’d be hard to detect.

    Facebook Authentication Bypass Using Shadow APIs

    Obscurity isn’t security, and determined attackers will find forgotten API hosts. The AppSecure cybersecurity research team found a way to gain access to any Facebook account via a couple of API endpoints Facebook forgot existed. The AppSecure team received a $15,000 bug bounty.

    Although found in 2016, this bug illustrates a kind of vulnerability prevalent in API architectures. This bug was subtle but demonstrated how the smallest crack could let an attacker run amok.

    The bug existed in Facebook’s password recovery logic. When a user requested to recover their account because of a forgotten password, they received a random six-digit code via text message. They enter the code in the browser, which sends an API call with the code.

    Facebook placed rate-limiting on the endpoint to protect against brute-force attacks. The API blocked client requests after 10 failed attempts. However, API endpoints existed on other hosts, and Facebook’s engineers didn’t realize it. An attacker could send payloads to “beta.facebook.com” and “mbasic.beta.facebook.com” and brute force the recovery code. These endpoints didn’t have the ten try limit.

    Check out our detailed post on this vulnerability for more on how modern app sec tools probably would’ve missed this vulnerability.

    Uber API BOLA Vulnerability

    Broken Object Level Authorization (BOLA) is number one on the API Top 10 list. Uber’s API had this vulnerability. Thankfully, it was discovered by security researchers before malicious actors did damage (as far as we know). But it illustrates well how dangerous BOLA can be.

    The vulnerability leaked sensitive information, including an authentication token that could be used to perform a full account takeover.

    The vulnerability appears when a new driver joins the Uber platform. The browser sends the “userUuid” to the API endpoint, and the API returns data about the driver used to populate the client.

    Unfortunately, the API endpoint didn’t check if the calling client had the authorization to view its returned details. An attacker could add another “userUuid” and get a sizable JSON object with the other user’s account details, including first and last name, email address, and user identifiers.

    This vulnerability illustrates that revealing too much information is dangerous for any API (Excessive Data Exposure is number three on the Top 10). Also, inadequate authorization checks can lead to account takeover with minimal effort.

    Check out our detailed post to learn more about this vulnerability.

    The Future of API Security

    Application security technologies such as Web Application Firewall, Next Generation Web Application Firewall, and Runtime Application Self-Protection don’t typically find the kinds of vulnerabilities we’ve discussed. These attacks present as ordinary traffic, so many defenses let them through.

    The future of API security lies with business logic. Application security tools have to understand the application’s context and business logic to know that non-managers shouldn’t be adding collaborators to a store or that a client shouldn’t access that user ID’s information.

    Traceable AI uses machine learning to learn the application’s business logic, so these types of attacks are found and stopped. See Traceable AI in action and see what the future of API security looks like.