StackHawk

Introducing StackHawk’s GitLab Integration: Unlock Full API Discovery for Your Code

Aaron White

We’re excited to share that StackHawk’s API Discovery feature now integrates seamlessly with GitLab! With this new addition, teams using GitLab can automatically uncover their APIs, microservices, and web applications and bring them under continuous security testing. Whether you’re on GitLab SaaS (Premium or Ultimate) or using a self-managed GitLab instance that’s publicly accessible, our new integration enables you to easily inventory and secure your API Attack Surface.

Why GitLab + StackHawk?

Automated Discovery: Instead of manually sifting through repositories, StackHawk analyzes your GitLab repositories to identify running testable applications and APIs, ensuring nothing goes unnoticed.
AI-Driven Insights: Accelerate your vulnerability protection with the power of AI, providing context and prioritization so you know where to focus your remediation efforts first.
Repository Insights: Beyond just finding endpoints, StackHawk offers commit history and framework details, giving security and development teams deeper visibility to plan tests effectively.
Enterprise-Ready: Available on the StackHawk Enterprise Plan, this integration is designed to tackle large or complex codebases with ease.

“StackHawk's API discovery notified us of a new repository within two minutes of commits being pushed and gave us an indication that it's a testable API with a postman collection in it. That's more than enough for us to start a

conversation with the developer to understand how we can get that under test.”

Importance of a Complete Attack Surface View

Modern applications often span multiple repos, microservices, and code bases. By connecting GitLab to StackHawk:

You gain a unified view of every Application and API across all your teams and projects.
You can shift security left by identifying vulnerabilities early, right at the code repository level.
You enable DevSecOps collaboration, with security directly integrated into developer workflows.

We now Support ALL the Major Source Code Management Systems

If GitLab isn’t your only code platform—no worries. Our coverage expands across GitHub, Microsoft Azure, and

Bitbucket too. No matter where your code lives, StackHawk has you covered.

Getting Started

Getting up and running is a snap:

Create a GitLab Group Access Token with the read_api scope.
Connect Your Group in StackHawk’s Integrations page.
Configure which repos to monitor on StackHawk’s Attack Surface screen.
Sit back as we discover your APIs and alert you to new endpoints and potential vulnerabilities!

Final Thoughts

Security can’t wait until after code is deployed. With StackHawk’s GitLab API Discovery integration, you no longer have to guess if you’re testing the entire application and API footprint. Try it out and see how you can proactively protect your APIs from the earliest phases of development through production.

Ready to Secure Your GitLab Repos?

Visit our API Discovery page or login to StackHawk to connect your GitLab instance today!

Why Legacy DAST Fails for Modern Applications and How to Fix It

Scott Gerlach

APIs ARE Your Application: So Why Aren't You Testing Them?

If you're still using legacy Dynamic Application Security Testing (DAST) tools to secure your APIs, you're leaving your biggest attack surface untested.

Legacy DAST was designed for a different era one where applications were server-rendered, HTML-based, and had a predictable structure. But today's applications aren't static web pages. They are API-first, often built with Single Page Applications (SPAs) that dynamically fetch data from backend services. APIs aren't just a supporting feature; they are the application.

Yet, most traditional DAST tools still rely on crawling web pages, looking for forms to submit, and using outdated session-based authentication. They completely fail to handle modern application security testing in an API-driven world

Let's dig into the details of why legacy DAST struggles with modern architectures, what's actually required to test API security, and how StackHawk built a modern DAST solution that developers can use to catch vulnerabilities before they ship.

Why Legacy DAST Falls Short in an API-First World

1. SPAs Broke the Traditional Crawling Model

Legacy DAST tools rely on crawling to discover attack surfaces. This means they scan an HTML page, extract all the links, follow them to new pages, and repeat the process to map out the application. This worked when applications were built as multi-page, server-rendered sites where clicking a link loaded a new page with a new set of form fields and inputs.

But modern SPAs don't work this way. Instead of loading new pages, SPAs dynamically fetch content from APIs and update the UI with JavaScript. This means:

No static URLs to crawl: An SPA might only load a single HTML page, with all application logic happening in the browser. Legacy scanners won't even see most of the functionality.
Navigation is handled in-memory: SPAs use JavaScript frameworks like React, Vue, and Angular, which update the page state dynamically without full-page reloads. A scanner that doesn't execute JavaScript fully won't even recognize when the app has navigated.
User interactions are event-driven: Clicking a button in an SPA often triggers an API call, not a traditional form submission. Legacy scanners, expecting standard web form inputs, miss these interactions entirely.
Even if the crawler uses Javascript technology to try to navigate the web page, it's a never ending task. When was the last time you got to the end of your Instagram feed.

For a security scanner, this means that the old method of crawling and form-based input testing is fundamentally broken. If a scanner can't reach functionality through HTML crawling, it can't test it for security risks.

2. APIs ARE the Application, And Legacy DAST Ignores Them

In traditional applications, business logic was executed on the server, and the frontend simply rendered the output. But in modern applications, the backend is an API that serves as the core of the application. The frontend, whether it's a web app, mobile app, or third-party integration, simply consumes the API.

This means that APIs are the real attack surface. A malicious actor doesn't need your UI to interact with your API; they can make direct API calls and attempt to exploit vulnerabilities.

Yet, most legacy DAST tools are still designed around web-based testing. They focus on clicking buttons, submitting forms, and testing page responses rather than interacting with APIs directly. If an API isn't exposed through a visible web form, legacy DAST won't find it, meaning it won't test it.

APIs are your application. Attackers don't need your UI to exploit your app, if they can reach your API, they can attack it directly. Yet most legacy security tools still treat APIs as an afterthought.

Attackers aren't waiting for a scanner to discover an API endpoint. They use tools like Burp Suite, Postman, and Fuzzers to test APIs directly. Security teams should be doing the same.

3. Authentication in Modern APIs Breaks Legacy DAST

Traditional DAST tools expect authentication to work in a simple, session-based way, log in with a username and password, receive a session cookie, and carry that cookie forward in all requests. But modern applications use API-first authentication mechanisms like:

OAuth 2.0
JSON Web Tokens (JWTs)
API keys and token-based authentication

These authentication models don't rely on session cookies, meaning a legacy scanner often can't authenticate properly. If a scanner can't authenticate, it can't test any API endpoints that require authorization, leaving huge portions of the application untested.

Login recorders are exacerbating the problem. Making complex authentication look simple is the goal, but completely misses the mark. This leads to busted authentication every few days and ineffective scans.

Modern API security testing needs to handle real authentication flows, such as retrieving OAuth tokens, passing API keys, and maintaining authorization state across multiple API requests. Legacy DAST simply isn't built for this.

4. Stateful API Workflows Aren't Tested

Many API vulnerabilities don't exist in a single request, they emerge when an attacker chains multiple requests together. This is particularly true for:

Broken authentication: Testing whether an expired or stolen token can be reused inappropriately.
Business logic flaws: Manipulating the sequence of API calls to gain unintended privileges.
Authorization bypasses: Checking whether certain actions are improperly exposed when replaying requests with modified parameters.

Legacy DAST tools operate in a stateless manner, meaning they send requests in isolation without maintaining API session state. If a vulnerability requires a specific sequence of actions to trigger, traditional scanning tools will miss it.

This is why API security testing must support stateful workflows, allowing testers to authenticate, retrieve tokens, make sequential requests, and analyze responses across multiple API interactions.

How StackHawk Solves API Security Testing

Instead of retrofitting crawling-based testing into an API-first world, StackHawk was built to test APIs directly, with features designed for how modern applications actually work:

1. Schema-Based API Testing

Instead of relying on web crawling, StackHawk ingests OpenAPI, GraphQL, gRPC, and SOAP schemas to identify API endpoints directly. This ensures that every API route is tested, not just the ones a crawler happens to find.

2. Direct API Security Testing

StackHawk sends API requests directly, applying security test cases to endpoints just like an attacker would. This eliminates the need for form-based input discovery and ensures that all attack surfaces are tested.

3. Full Authentication Support

StackHawk handles real API authentication methods, including OAuth, JWTs, and API keys. It authenticates like a real client, meaning authenticated API routes are actually tested. Oh, and we cover custom auth flows that someone might have built after drinking too much coffee.

4. Stateful API Workflows

StackHawk can execute sequences of API requests to test vulnerabilities that only appear in multi-step workflows, like authentication failures, session manipulation, and authorization bypasses.

5. Built for CI/CD

Unlike traditional security tools that run infrequently as part of separate security audits, StackHawk integrates into CI/CD pipelines, allowing security tests to run automatically during development. This means security issues are caught early, when they are easiest to fix.

Why This Matters for Application Security

Legacy DAST tools weren't built for API-first applications, and retrofitting them to work in a modern security pipeline is an exercise in frustration. Crawling doesn't work, authentication is broken, and APIs the actual attack surface go untested.

If you're serious about application security, you need security testing that treats APIs as first-class citizens. StackHawk is built for exactly this purpose: API-native security testing that fits into modern development workflows.

APIs are your application. If you're not testing them properly, you're leaving your app exposed.

Stop Reacting, Start Testing: A Dynamic Approach to Runtime Security

Nicole Jones

Over the years, "runtime security" has become a bit fuzzy, often used interchangeably with various tools and methodologies. However, not all runtime approaches are created equal. We're diving deep into the core of runtime security, separating myth from reality and highlighting why a dynamic approach to runtime testing is crucial for your security program.

Introduction to Runtime Security

When we talk about runtime security, we're essentially addressing the vulnerabilities or suspicious behavior that manifest when an application is actively running. This is where the rubber meets the road, where theoretical vulnerabilities become real-world threats. But what does runtime security actually entail?

First, you must understand that not all runtime solutions are the same. Many confuse runtime monitoring with runtime testing and miss the opportunity to enhance the overall security posture of their attack surface. Let's break down the differences and explore why a proactive testing approach, specifically Dynamic Application Security Testing (DAST), stands out.

Understanding Runtime Security Testing and DAST

At its core, runtime security testing involves evaluating an application's security while it's running (obviously). DAST is a prime example of this methodology. It simulates real-world attacks to identify vulnerabilities that can be exploited. This approach is beneficial because:

Real-World Exploitation: Unlike static analysis tools that examine code in a non-running state, DAST uncovers vulnerabilities that are exploitable in live environments.
Contextual Findings: DAST provides context by showing how vulnerabilities can be chained together to compromise an application, offering a clearer picture of the actual risk.
Comprehensive Coverage: DAST can uncover vulnerabilities other tools might miss, such as configuration issues or interactions between different components.

Distinction Between Testing and Monitoring

A common misconception is that runtime monitoring is equivalent to runtime testing. While monitoring tools are vital in observing application behavior and detecting anomalies, they don't actively probe for vulnerabilities or inform you where the issue exists in the code.

Runtime Testing (DAST): This happens before code is pushed to production and actively probes for vulnerabilities by simulating attacks. It's about identifying and validating exploitable weaknesses before malicious actors can leverage them in the wild.
Runtime Monitoring: This happens once the software is in production and focuses on observing and alerting on deviations from expected behavior. It's about detecting anomalies and potential threats in real time.

To illustrate the difference, think of it this way: Testing is like making sure every door to your house is shut and effectively locked to prevent intruders from entering. Monitoring is like watching an intruder steal your TV from your security camera feed.

Testing tells you what is wrong and how to fix it before something goes live, while monitoring tells you if something is wrong after it is live.

Comparing Security Testing Approaches: Why DAST Stands Out

Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Secrets Management tools find potential vulnerabilities, but DAST finds real, exploitable issues.

SAST and SCA analyze code and dependencies for known vulnerabilities, but they can produce false positives and may miss runtime-specific issues, such as misconfigurations in IAC.
Secrets Management ensures sensitive data is not exposed, but it doesn't test how those secrets are used in a running application.
DAST, on the other hand, validates vulnerabilities in a live environment, providing concrete evidence of their exploitability. This prioritization and context are what sets DAST apart.

Misconceptions About Runtime Security

One of the main misconceptions is the idea that runtime testing is solely a production activity. That is false. Modern DAST can and should be integrated throughout the software development lifecycle (SDLC).

Pre-Production Testing: DAST can be used in staging and testing environments to identify vulnerabilities before they reach production.
Continuous Testing: Integrating DAST into CI/CD pipelines enables continuous security testing, ensuring that vulnerabilities are identified and addressed early.
Production Testing: With proper safeguards, DAST can also be used in production to validate security controls and identify emerging threats.

Another major misconception is that all runtime tools provide the same level of security. As mentioned above, monitoring and testing are distinct disciplines. Relying solely on monitoring is a reactive approach that can leave critical vulnerabilities undetected and lack the proper context to fix quickly when suspicious behavior is detected.

While "runtime security" may have become diluted over the years, its core purpose remains critical: identifying and fixing vulnerabilities in live applications. By understanding the distinction between runtime monitoring and dynamic testing, organizations can move beyond reactive measures and adopt a proactive security posture. DAST's ability to simulate real-world attacks in pre-production environments, provide contextual insights, and offer comprehensive coverage makes it an effective solution for any security program. Embracing a dynamic approach to runtime testing throughout the SDLC ensures that vulnerabilities are not just detected but actively addressed, ultimately strengthening your security program and protecting your applications from real-world threats.

The Ultimate Guide to Choosing an API Testing Framework

StackHawk

APIs (Application Programming Interfaces ) are critical in linking applications and services, ensuring seamless digital interactions. However, API failures can lead to significant issues like transaction errors, login problems, and data breaches, negatively impacting user experience and business operations.

This blog post breaks down API testing frameworks, offering insights to help developers choose the right tools for effective API testing. We'll dive into the essentials of API testing and its importance and address emerging challenges in the field.

What is API Testing?

API testing evaluates the performance, security, and reliability of application programming interfaces. It focuses on the "business logic layer" of software architecture, where data exchange and processing occur. Unlike UI testing, which is directed at assessing the user interface, API testing delves into the core functionality of the application, establishing it as an essential component of the software testing process within the software development lifecycle (SDLC).

API testing involves sending various requests to the API to validate API responses. These requests simulate real-world interactions with the API, such as user logins, data retrieval, or order processing. As testers, we examine the responses for accuracy, completeness, speed, and security. This process helps identify bugs, vulnerabilities, and performance bottlenecks before they impact users.

Ideally, the API used for executing test cases should closely mirror the production API your customers interact with. This ensures that new features or fixes work as intended under real-world conditions.

To conduct effective API testing, developers need a solid grasp of the API's specifications and expected functionality. Utilizing API testing tools, they should implement a comprehensive API testing process that includes designing test cases for a broad spectrum of scenarios—normal operations, edge cases, and error scenarios. This approach, particularly when automated API testing is employed, ensures the API performs reliably across different situations and fulfills the established criteria.

Testing APIs encompasses a variety of techniques and approaches, which we'll discuss soon. For example:

Functional testing to verify individual API endpoints
Load testing to assess performance under stress
Security testing to identify vulnerabilities

The right API testing tools and framework aim to automate these processes and achieve comprehensive coverage. For example, StackHawk specializes in dynamic application security testing (DAST) to identify and fix vulnerabilities early in the development process. The specific methods and tools employed depend on the complexity of the API, the development environment, and your overall goals for software testing.

Benefits of API Testing

API testing offers significant advantages that contribute to faster development cycles, improved software quality, and enhanced user experiences.

Enhancing Software Quality

Robust API testing ensures that APIs work correctly across various scenarios by uncovering functional, performance, and security issues. Automated tests detect regressions and inconsistencies early, reducing the technical debt and maintenance workload, which translates into higher code quality and system reliability.

Reducing Development Costs

Early detection of issues through efficient API testing significantly reduces development costs by catching errors before they become expensive to fix post-deployment. By integrating automated testing tools into the software development process, teams minimize manual labor and decrease the risk of errors, enabling continuous validation of changes. This efficiency prevents costly later-stage corrections and allows developers to focus more on delivering high-quality software components quickly.

Supporting Faster Time-to-Market

API testing can accelerate software development by using a continuous integration (CI) process within the CI/CD pipeline. Using automated tests, teams can continuously validate API functionality, security, and performance with every code commit. This constant verification enables quicker feedback loops and equips teams to iterate rapidly and push high-quality applications to market with greater velocity.

Ensuring Seamless Integration

APIs bridge the communication gap between disparate systems and services, with API testing being the gatekeeper that ensures smooth interactions post-updates. By rigorously checking compatibility, reliability, and data integrity, API testing mitigates the risk of integration breakdowns, laying the groundwork for scalable, interoperative software ecosystems.

Enhancing Security and Reliability

During API testing, security assessments are crucial for spotting vulnerabilities such as insecure authentication, data exposure, and SQL injection. Employing security-focused testing tools enables businesses to uncover and mitigate potential risks, enhancing API security. Automating security validations ensures ongoing protection with minimal manual oversight, thereby increasing efficiency. Robust and secure APIs boost user trust and adoption, underpinning the application's reliability and market success.

Improving User Experience

The performance of APIs is a critical determinant of user satisfaction. Investing in the best API testing tools simplifies the process of ensuring APIs can manage fluctuating traffic, unexpected inputs, and edge cases effectively. These testing tools provide real-time feedback and actionable insights, enabling quick resolution of performance issues. Integrating these tools into your development process instills confidence that the app will provide a seamless and dependable user experience in production environments.

Types of API Testing

API testing requirements combine various approaches to achieve comprehensive coverage across functionality, performance, and security. Each type of testing addresses specific goals, like validating behavior, identifying vulnerabilities, or ensuring compatibility. Together, they help teams deliver reliable, secure, and high-performing APIs.

Functional Testing

Functional API testing assesses if an API performs as anticipated by validating its essential functions, such as request handling, data processing, and accurate response delivery. This ensures the API fulfills business demands and provides consistent outcomes under standard conditions. For instance, to confirm that a user authentication API operates correctly, functional testing could involve sending requests with both valid and invalid user credentials. In this case, the test would expect the API to successfully authenticate requests with valid credentials, returning a 200 status code, while rejecting requests with invalid credentials by returning a 401 status code, thereby proving the API’s capability to handle authentication accurately.

Regression Testing

Regression testing ensures that changes to the API, such as updates or bug fixes, do not break existing functionality. This type of testing really comes in handy in iterative development, where frequent changes can inadvertently introduce new issues. For example, a regression test might confirm that an API update that adds real-time order tracking doesn't disrupt existing checkout or payment processing endpoints. Through regular and automated regression testing, you can maintain stability and prevent unexpected failures during development.

Performance Testing

Performance testing measures the API’s responsiveness, scalability, and stability under various workloads. It ensures the API performs efficiently during normal operations and under peak traffic conditions. For example, load testing evaluates how the API handles high traffic volumes, while stress testing pushes the API to its limits to identify potential bottlenecks. Performance testing helps you guarantee great user experiences, even during unexpected traffic spikes or heavy usage.

Compatibility Testing

Compatibility testing ensures the API works correctly across different environments, platforms, and configurations. It validates that the API functions consistently regardless of the client application, operating system, or browser. For example, testing an API on multiple versions of iOS and Android ensures mobile users experience consistent functionality. APIs that interact with diverse systems and user bases must perform thorough compatibility testing.

Validation Testing

Validation testing focuses on the overall correctness and completeness of the API. It combines functional, performance, and security testing so the API meets design specifications and business requirements. For example, a validation test might verify that an API providing stock market data returns accurate, timely information within acceptable performance thresholds.

Integration Testing

Integration testing assesses how well the API interacts with other components, services, or APIs. It verifies that data flows correctly between systems and that there is smooth communication across interconnected services. For example, testing an API’s ability to send data to a third-party payment gateway ensures that transactions are processed without errors. Integration testing minimizes risks associated with system dependencies and complex workflows.

Key Features of an API Testing Tool

Let's discuss the essential features that we recommend you consider when deciding on one for yourself:

Ease of Use

An API testing tool must offer a user-friendly interface and simple workflows, paired with clear documentation, to facilitate simple API testing and enable teams to concentrate on quality rather than learning how to use the tool. Features like pre-set test templates and drag-and-drop functions can greatly simplify API testing.

Integration with CI/CD Pipelines

Effective API testing tools integrate seamlessly with CI/CD workflows to support continuous testing. With CI/CD integration in place, every code update triggers automated API tests, providing immediate feedback on changes. API test automation reduces manual effort and minimizes the risk of deploying faulty APIs. This way, as we discussed earlier, you catch and resolve bugs early rather than later, accelerating the development process while maintaining high quality.

Scalability and Performance

Modern APIs must handle diverse workloads, from low-traffic scenarios to sudden spikes. A robust API testing tool must support scalable testing across varying traffic levels. For example, tools that enable stress and load testing can simulate real-world usage to evaluate API performance under pressure. A scalable tool can adapt to growing API ecosystems without sacrificing accuracy or efficiency, especially for businesses managing large-scale applications.

Support for Multiple API Protocols

An ideal API testing tool should accommodate diverse messaging protocols—REST, GraphQL, SOAP, and others—enabling thorough testing across all API types. For instance, a tool adept at testing both RESTful services and GraphQL APIs demonstrates versatility for mixed protocol environments. Such multi-protocol support streamlines the testing workflow, eliminating the necessity for numerous tools and simplifying the overall process. Ensuring robust messaging protocol testing capabilities guarantees reliable API performance, irrespective of the underlying architecture.

Real-Time Reporting and Analytics

To truly capitalize on API testing, it's crucial to get immediate, meaningful feedback. Tools packed with powerful reporting and analytics features enable teams to quickly digest test outcomes, pinpoint problems, and observe patterns. Imagine getting real-time updates on test pass rates, response times, and errors - this kind of insight allows for swift action. Such detailed visibility into an API’s performance and health means issues can be addressed on the spot, significantly boosting API reliability. Real-time analytics streamline this process, making it simpler to maintain high-performing APIs.

Security Testing Features

Security testing safeguards APIs against vulnerabilities and threats. A robust testing tool should detect issues like SQL injection, broken authentication, cross-domain misconfiguration, and other vulnerabilities while providing actionable feedback for remediation. It should also help maintain compliance with standards like OWASP Top 10. For example, validating an API’s token-based authentication ensures that only authorized users gain access. Furthermore, by integrating security testing steps into CI/CD pipelines, you can establish automated scans so teams can identify and address potential risks during development, reducing the likelihood of breaches.

Top API Testing Tools

Now that we've discussed the features of an ideal testing tool let's discuss some of the best API testing tools currently available.

StackHawk

StackHawk is a developer-focused API security testing platform that helps teams secure their apps and APIs. You can run it locally and integrate it with CI/CD pipelines and your existing developer workflow tools like GitHub, AWS, Snyk, and Azure DevOps. Combining with StackHawk's modern dynamic application DAST features, you can identify and resolve your app's attack surface as early as possible in SDLC. StackHawk takes the point-of-view of an attacker and simulates attacks on a running version of your app. This way, it accurately captures all possible attack vectors for a production system.

StackHawk supports REST, GraphQL, SOAP, and gRPC APIs to provide comprehensive test coverage across diverse architectures. Moreover, it embeds automated OWASP Top 10 vulnerability scanning directly into workflows. StackHawk further differentiates itself by delivering real-time, actionable feedback that developers can use to remediate vulnerabilities immediately. StackHawk designs security reports with practicality in mind, highlighting risk levels, affected endpoints, and remediation guidance.

Postman

Postman is a versatile tool widely used for functional and exploratory API testing. Here are some of its key features:

An intuitive interface that simplifies the API automation.
Built-in tools for API monitoring, environment management, and team collaboration.
Advanced scripting for dynamic test cases and automated workflows.
Extensive integrations with tools like Slack, GitHub, and Jenkins.

Postman offers excellent utility for teams focused on collaboration and API lifecycle management.

Katalon Studio

Katalon Studio offers an all-in-one testing platform for APIs, web, and mobile apps. Its unique features include the following:

No-code testing for non-technical or less technical users, alongside scripting options for advanced users.
Built-in templates and plugins for quick test case creation and execution.
Comprehensive analytics dashboards for tracking test performance.
Support for hybrid testing, combining REST and SOAP APIs with web and mobile functionalities.

If you need a versatile and user-friendly solution across multiple platforms, Katalon Studio can be an ideal choice.

SoapUI

SoapUI, a headless functional testing tool, can create complex and data-driven test scenarios for API validation. Here are some of its core strengths:

Comprehensive support for SOAP APIs, with additional functionality for REST API testing.
Advanced scripting to design highly customizable test cases.
A focus on load testing with the ability to simulate large-scale traffic scenarios.
Tools for security and compliance testing, particularly in legacy systems.

JMeter

JMeter specializes in performance and load testing for APIs. Its standout features include the following:

The ability to simulate millions of users and evaluate API stability under extreme conditions.
Extensive support for custom scripting for tailored performance testing.
A lightweight, open-source framework with high scalability.
Detailed performance metrics for assessing response times, throughput, and error rates.

Choosing the Right API Testing Framework

Choosing the right framework begins with understanding your requirements. Identify whether you want to focus on functional, performance, or security testing—or a combination of these. For example, if security is at the top of your business's mind, consider StackHawk, which integrates smoothly into your existing development workflows and automates vulnerability detection.

A testing framework must fit into your existing development and CI/CD workflows without breaking or disrupting anything. Look for tools that you can use to create automated API tests during builds and deployments. Support for platform integrations like Jenkins, GitHub Actions, or GitLab pipelines gives you strong automated testing workflows that run continuously without manual intervention on trigger events like code pushes. In this regard, StackHawk has been built for continuous integration and deployment workflows while supporting local development.

APIs may use protocols like REST, GraphQL, SOAP, or gRPC. The framework must support your architecture of choice. Tools with broad protocol compatibility provide flexibility for evolving systems. If you opt for a tool with comprehensive protocol support, you don't have to worry about adopting multiple tools, simplifying workflows, and saving valuable resources. StackHawk supports all of the aforementioned protocols for secure testing across various API types.

For most businesses, making APIs secure against vulnerabilities across the entire attack surface is an absolute must. Therefore, security testing and the tool in question must naturally fit into DevOps so you can catch threats as early as possible. Having developer-friendly feedback in real-time directly within test workflows can greatly enhance how you address issues without slowing down delivery times. For example, a pre-deployment scan using StackHawk can flag insecure endpoints, like an API missing input sanitization, and suggest fixes immediately.

Testing frameworks must adapt to your organization’s needs and scale as your API ecosystem grows. Custom scripting allows teams to write tests tailored to unique requirements and business logic. With scalability, the framework handles increasing API traffic and complexity. By choosing a scalable framework, you future-proof your testing strategy and support long-term growth.

Lastly, evaluate the user-interface of the tool to reduce the learning curve for developers and QA teams. Look for tools with intuitive and user-friendly interfaces, clear documentation, and strong community support. These features help teams adopt the tool quickly and use it effectively. A framework that prioritizes developer experience is easier to adopt and has less time-to-value.

StackHawk directly integrates with existing development tools and provides actionable feedback reports at scale in real-time. This empowers developers to identify and fix threats and makes the process more accessible to them. Application security no longer remains something that gets delegated to a separate security team but to those building the product itself. This promotes a security-first mindset in developers and, therefore, results in more secure software components.

Building an API Testing Framework from Scratch

Building an in-house API testing framework might become necessary to suit specialized requirements and setups. Let's discuss the general steps and guidelines to follow while implementing such a framework from scratch.

Define objectives and scope: Before building an API testing framework, clearly define your goals and scope. Identify the types of APIs you need to test, such as REST, GraphQL, or SOAP, and the key testing areas like functionality, performance, and security. Determine whether the framework will focus on automated regression tests, load testing, or security scans. Consider your team’s technical expertise and the resources available for development and maintenance. These factors guide the design and ensure the framework aligns with your organization’s needs.
Choose programming language and framework structure: Select a programming language that fits your team’s skill set and integrates well with your tech stack. For example, Python works well for its simplicity and support for libraries like `requests` for API interactions and `pytest` for testing. Define a modular structure for your framework to separate concerns like test data, test cases, and configuration files. Modularity makes the framework easier to maintain and extend. A well-suited language and structure gives you scalability and long-term usability.
Implement automated test suites: Automation must be one of the top priorities for reducing manual effort and maintaining consistent test execution across development cycles. Create test suites for functional, performance, and security testing. Include automation for regression tests to make sure changes don’t break existing functionality. Use tools or libraries like `pytest`, JUnit, or Selenium (if you have UI components) to streamline test execution and reporting.
Integrate with CI/CD pipelines: Integrating the framework into your CI/CD pipeline enables continuous testing at scale. Set up triggers to execute tests automatically whenever code changes or builds occur. Use platforms like Jenkins, GitHub Actions, or GitLab CI/CD. Include pre-deployment tests that verify API performance and security before releasing to production. Continuous testing helps detect and resolve issues early and delivers quality software to end users that perform as expected.
Prioritize security testing: Embed security testing into your framework to address vulnerabilities and security weak points that malicious parties can exploit. Use security-focused tools like StackHawk and integrate them into your development workflows to make security a part of your development cycles. Automate common security tests, for example, validating authentication mechanisms and simulating attack scenarios. Make sure reports provide actionable information that developers can use to fix issues without slowing down the development cycle.
Support data-driven testing: Incorporate data-driven testing to validate API behavior across multiple input sets. Use reliable and external sources to provide dynamic inputs for test cases. For example, you can test a user authentication API with various combinations of valid and invalid credentials. It achieves comprehensive coverage and identifies edge cases that may not surface in static tests. Data-driven testing makes the framework flexible and thorough.
Provide Detailed Reporting and Analytics: The framework should generate clear, actionable reports after every test run. Include metrics like test success rates, response times, and error rates. Use reporting libraries or integrate third-party tools to visualize data and trends. You must have a clear idea of how to prioritize critical vulnerabilities and properly triage to maximize post-test issue resolution. For example, a report highlighting slow API endpoints helps you prioritize and strategize performance optimizations.
Design for scalability and flexibility: Make sure your framework can scale with growing testing needs and adapt to new requirements. Use modular components, such as plugins or libraries, to extend functionality as you need. For example, adding GraphQL support to an existing REST-focused framework should require minimal changes. Avoid hardcoding configurations or test data to maintain flexibility. A scalable design future-proofs the framework so it remains effective over time.

API Testing Best Practices in a DevOps Environment

API testing is integral to DevOps, ensuring APIs behave as expected throughout development and in high-scale production. Automated API tests woven into CI/CD pipelines catch issues instantly, allowing for bug-free production pushes and swifter, more dependable rollouts. This practice cements DevOps's commitment to rapid delivery without sacrificing quality.

Embracing the shift-left principle, DevOps prioritizes early problem detection. API testing reinforces this by integrating tests upfront, such as handling edge cases like expired tokens for solid security out of the gate. Early detection curbs bug proliferation, conserving time and resources. This method aligns with agile and DevOps, fostering quick feedback loops and accelerated iteration. Follow these best practices to optimize your API testing process and maximize its benefits for high-quality applications:

Automate repetitive tasks like regression and functional tests to save time and reduce human error. Integrate automated tests into CI/CD pipelines to ensure continuous validation with every code change.
Test your API's functionality, including the edge cases, under diverse conditions. Include security and performance tests to make sure APIs stay secure, robust, and reliable.
Incorporate security validation during the earliest development stages.
Evaluate API performance under varying conditions to ensure scalability and stability. Use metrics like response times and error rates to identify areas for improvement.
Run tests in environments that mirror production settings as closely as possible.
Review and update tests as APIs evolve. Add new scenarios so that coverage remains relevant to the current state of your product.

Common Challenges in API Testing

To successfully implement API testing, it's important to be aware of the common challenges and pitfalls. Let's look at some of these challenges and try to understand how to address them.

Comprehensive coverage: Ensure your API testing includes every aspect and potential error scenario. Overlooking edge cases (e.g., unexpected input formats or uncommon data combinations) could cause undetected issues, leading to production disruptions. For instance, if your API processes dates, validating against incorrect formats is crucial. Inadequate test coverage exposes APIs to production failures and security vulnerabilities. Implement exhaustive test plans and embrace automation for varied input handling.
Test data management: Handling test data, particularly with APIs that process dynamic or sensitive data, presents challenges. Simulating realistic scenarios without exposing real user data requires careful planning. Achieving clean, consistent, and reusable test data across testing stages demands sophisticated strategies. Adopt data-driven testing, using external sources for input sets in formats like JSON or CSV, and anonymize sensitive data to ensure privacy compliance while preserving test accuracy.
Handling dependencies: API dependencies on external services can introduce complications. An unavailable third-party service, like a payment gateway, can hinder testing efforts. To mitigate these challenges, employ mocking to simulate dependencies, enabling isolated API testing. Tools such as Postman or WireMock facilitate testing by generating mock responses, streamlining the testing process despite external dependencies.
Security testing integration: Given the vulnerability of APIs to various attacks, incorporating security testing is non-negotiable. Insecure endpoints can lead to serious breaches. Continuously update your security testing practices and tools, like StackHawk, to proactively identify and fix vulnerabilities. Integrating security testing within your CI/CD pipelines ensures consistent, thorough validation, keeping pace with evolving security threats.
Load Testing for Performance Validation: To maintain performance regardless of traffic spikes, utilize load testing tools (e.g., JMeter) to simulate varying loads. Evaluating performance through metrics such as response times and error rates is critical for identifying optimization opportunities. Performance testing guarantees API stability across real-world usage scenarios.
Environment-specific testing: APIs can exhibit different behaviors across development, staging, and production due to configuration variances. Discrepancies between environments, like database performance differences, highlight the need for comprehensive environment testing. Ensure your testing regimen accounts for these differences to spot potential issues before production deployment.

Future Directions for API Testing

To address the growing complexity of our digital infrastructure, the modern challenges and demand, it's important to evaluate how the future of API testing is shaping up. APIs drive growth, and by evaluating the future trajectory and emerging trends, we can find new business opportunities and growth potential.

AI-Driven testing: AI is set to streamline API testing by using historical data to predict failures and optimize test cases. Expect AI to enhance risk assessment and craft test scenarios for edge cases.
Real-time monitoring: The importance of real-time monitoring will grow, with predictive analytics anticipating performance issues. This will establish feedback loops for adaptive APIs in production environments.
Microservices compatibility: Testing must evolve to handle the complexity of microservices architectures, focusing on dynamic contract validation and overall system behavior to ensure seamless integration.
Cross-cloud validation: As APIs are deployed across various cloud environments, testing tools will need to assure consistent performance amidst diverse network conditions.
Security testing advancements: With rising security threats, testing will incorporate AI for threat modeling and automated penetration testing, especially against protocols like GraphQL and WebSocket, to maintain robust defense mechanisms.

Conclusion

A solid API testing framework ensures your APIs are dependable, secure, and high-performing, contributing to a seamless user experience and growth.

The future of API testing hinges on smarter, adaptable, and integrated solutions. Teams that leverage new testing technologies can create superior APIs and outpace competitors, with security being a fundamental component.

StackHawk provides developer-centric security testing designed for today's application needs, with automation at its core. Sign up for a free trial to see how it can enhance your API testing strategy.

Top Strategies for Node.js API Security: Best Practices to Implement

Matt Tanner

If you're creating applications in Node, chances are that you've got some APIs that are floating around. Node.js APIs are commonly used to exchange sensitive data and provide access to critical application functionality. This makes securing them essential to prevent data breaches and keep your system working as intended. Failing to implement proper security measures can leave your application vulnerable to attacks, compromising user data and potentially damaging your reputation in terms of security.

This article outlines key strategies to secure your Node.js APIs, covering topics like input validation, authentication, authorization, and protection against common threats. Implementing these practices can significantly reduce your application's attack surface and ensure your data remains protected. Let's get started by understanding a bit more about security regarding Node.js APIs.

Understanding Node.js API Security

Securing your Node.js API involves understanding potential vulnerabilities and implementing measures to mitigate them. Common threats that these types of APIs generally come across include:

SQL Injection: Manipulating user input to execute malicious SQL code against your database.
Cross-Site Scripting (XSS): Injecting malicious scripts into web pages viewed by other users.
Cross-Site Request Forgery (CSRF): Tricking a user's browser into performing unwanted actions on your application.
Denial-of-Service (DoS): Flooding your API with requests to make it unavailable to legitimate users.

The actual mechanisms to exploit any of these vulnerabilities tend to range pretty widely. Prevention comes in many different forms, spanning from how you write your code to how you deploy and monitor it. To address these and other vulnerabilities, you need to implement a multi-layered security approach for REST API security that includes:

Input Validation: Strictly validating all user input to ensure it conforms to expected data types, formats, and ranges.
Authentication and Authorization: Verifying user identities and controlling access to resources based on their roles and permissions.
Secure Data Storage and Transmission: Protecting data at rest and in transit using encryption and secure storage practices.
Error Handling and Logging: Implementing error handling best practices to prevent information leakage and logging security events for analysis and incident response.

Understanding what vulnerabilities could be exploited and actively seeking to prevent and monitor them forms the basis of your defenses. Of course, understanding what attacks could occur and actually preventing them are completely different sides of the coin. So, what does it take to prevent these attacks? Let's take a look at some of the most common types of attacks and potential ways to mitigate them.

Protecting Against Common Attacks

Common attacks are exactly that: those vulnerabilities that are most often exploited. These are the most often exploited because they tend to be the most prevalent gaps within application security. This means that protecting your Node.js API from common attacks is vital for maintaining its integrity and availability. Here is a high-level view of some key strategies to implement to combat against them:

Cross-Site Request Forgery (CSRF) Protection

Use Anti-Forgery Tokens: Generate unique tokens for each user session and include them in forms and requests. This prevents attackers from submitting unauthorized requests on behalf of a user. Libraries like csurf can help implement this in your Node.js application.
Enable HTTP Strict Transport Security (HSTS): Force browsers to communicate only with your API over HTTPS, preventing attackers from intercepting requests and responses.

Learn more about CSRF attacks in Node.js and how to prevent them.

SQL Injection Prevention

Use Parameterized Queries: Never directly concatenate user input into SQL queries. Use parameterized queries or prepared statements to prevent attackers from manipulating your queries.
Employ an ORM (Object-Relational Mapper): ORMs like Sequelize and TypeORM can help prevent SQL injection by abstracting database interactions and automatically escaping user input.

Learn more about what Node.js SQL Injection attacks look like and how to prevent them.

Denial-of-Service (DoS) Mitigation

Rate Limiting: Limit the number of requests a user or IP address can make within a specific timeframe. This helps prevent attackers from overwhelming your API with traffic.
IP Blocking: Block requests from known malicious IP addresses or ranges.
Use a Web Application Firewall (WAF): A WAF can help detect and block malicious traffic before it reaches your API. Consider cloud-based WAF solutions like AWS WAF, Cloudflare, or Imperva.

Regular Security Audits and Penetration Testing

Automated Scanning: Use tools like StackHawk to automate security testing and identify vulnerabilities in your API. StackHawk can scan your API for common vulnerabilities like OWASP Top 10 and provide detailed reports and remediation guidance.
Manual Penetration Testing: Engage security professionals to conduct manual penetration testing to uncover more complex vulnerabilities.

As you can see, some of these prevention strategies lie within the code, and others require additional tools to implement or sit at the infrastructure level. By implementing these strategies and regularly testing your API's security, you can significantly reduce the risk of these common attacks being successful. At the end of the day, these efforts help to protect your application and its users.

Next, let's start to break down more of the particulars. In the next five sections, we will look at how to prevent many of the exploits mentioned above. When combined, these will give your application and APIs a rock-solid foundation for security. Let's start by looking at securing user input, one of the main ways to stop exploits such as SQL injection.

Securing User Input

Failing to secure user input properly is one of the most common causes of security vulnerabilities. Attackers can exploit weaknesses in input validation through brute force attacks or otherwise by injecting malicious code, manipulating data, and gaining unauthorized access to your system.

To mitigate these risks, secure APIs should:

Validate all input: Treat all user-supplied data as potentially malicious. Validate data types, formats, lengths, and ranges to ensure they meet your application's requirements.
Sanitize data: Escape or remove special characters that could be used to execute code or manipulate your database.
Use a validation library: Leverage libraries like Express-Validator to simplify input validation and enforce consistent rules across your application. This library provides a wide range of validation methods and allows you to define custom validation rules.

The nice part about libraries like Express-Validator is that they provide a lot of pre-canned filters that you can easily apply to sanitize input. Here is an example of how it can be used to validate parameters in the body of an API request, such as username and password.

You can significantly reduce the risk of injection attacks and other vulnerabilities by rigorously validating and sanitizing user input. If a front-end UI uses your APIs, it's also a great idea to have checks in place there, too, but don't rely solely on front-end validation and forego it at the API level. Much of the logic in the UI can be easily bypassed, especially if a user issues requests directly to the API.

Authentication and Authorization

The next and most critical points to touch on are authentication and authorization. The mechanisms that implement this are fundamental to API security, helping to authenticate users and controlling access to resources. You can implement these security measures at different levels, offering flexibility and in-depth defense. Let's look at a few of the places where authentication and authorization practices can be included in our applications and APIs.

Application-Level Implementation

JWTs (JSON Web Tokens): JWTs remain a popular choice for secure information transmission. Libraries like jsonwebtoken simplify JWT management in Node.js.
Role-Based Access Control (RBAC): Define roles with specific permissions and assign users accordingly, ensuring they only access necessary resources.

Adding JWT support to your Node application is relatively easy to do. By using jsonwebtoken, you can easily verify that a token is valid. You should also ensure that a user is authorized to access the resources they are trying to reach, usually done by validating the JWT's claims. This will reveal what scope that user should have access to. Below is a simple example of how to extract a JWT from a header and verify that the JWT is legitimate and hasn't been tampered with. You can see that the authenticateToken middleware function is injected into the /protected route.

Using an API Gateway

One of the easiest ways to implement centralized authentication and authorization is through an API gateway. By using a gateway, you can abstract security logic into the API management layer and worry less about it in your code. Generally, the API gateway is set in front of your APIs, and all requests must be proxied through the API gateway to get to the underlying API. This means that the gateway can enforce various security measures. The benefits of this include:

Offloaded Logic: Handle authentication and authorization at the gateway level, reducing application code complexity and ensuring consistency.
Enhanced Security: Benefit from built-in security features like rate limiting, IP whitelisting, and protection against common web attacks.
Integration with Identity Providers: Seamlessly integrate with providers like Okta, Auth0, and AWS Cognito for streamlined user management.

Various gateway platforms exist, and some, such as AWS API Gateway and Azure API Management, are available directly through cloud vendors you likely already use. Of course, there are many others, such as Kong and Tyk, that are bringing the latest tech to the API management space and offering capabilities beyond the cloud-vendor API management platforms. For those who are familiar with TypeScript and want to play in an environment closer to their Node.js roots, Zuplo is also a good option and highly lightweight.

By combining application-level and API gateway approaches, you create a layered security model, enhancing protection and simplifying management. This allows for flexible and robust authentication and authorization tailored to your API's specific needs.

Secure Data Storage and Transmission

With data flowing to and from APIs, including the services that the API itself corresponds with, data storage and transmission are critical to keeping data secure. Protecting sensitive data in transit and at rest is critical for maintaining user trust and complying with data privacy regulations.

Data in Transit

When we talk about "data in transit," this is when data is moving between services, "on the wire," some may say. Although there are plenty of technologies that can aid with security here, there are two that stand out as must-haves the majority of the time. These include:

HTTPS Everywhere: Enforce HTTPS for all API communication. This encrypts data transmitted between the client and server, preventing eavesdropping and tampering. Obtain an SSL certificate and configure your server to use HTTPS.
Consider TLS Pinning: For mobile applications, consider implementing TLS pinning to prevent man-in-the-middle attacks. This involves hardcoding the server's certificate fingerprint in the application, ensuring it only communicates with the legitimate server.

Data at Rest

For "data at rest," think of where the data will continue to reside after it transits the system. This could include application-level databases, like Postgres or MySQL, or even intermediate caching and in-memory databases, like Redis. Regardless of where the data lands, you want to take a few best practices

Encryption: Encrypt sensitive data stored in databases or other storage systems. Use strong encryption algorithms and securely manage encryption keys.
Secure Password Storage: Never store passwords in plain text. Use robust hashing algorithms like bcrypt to hash passwords before storing them. Libraries like bcrypt can help implement this in your Node.js application.
Data Minimization: Only collect and store the data that is absolutely necessary. This reduces the risk of data breaches and helps comply with data privacy regulations.

For instance, if you wanted to hash passwords when storing them in the database, you could use a library like bcrypt to do so. The following code snippet is an example of how you could use bcrypt's .hash() function to store the password as a hashed value in a database and then how the .compare() function can be used to validate the password again at login.

By implementing these practices, you can ensure that your API's data remains confidential and protected from unauthorized access during transmission and while at rest within different types of data stores your APIs and applications may use.

Error Handling and Logging

As developers, we want to make sure that consumers of our APIs receive accurate and detailed error responses. However, there is a delicate balance between "just enough" and "too much" detail. Proper error handling and logging are essential for maintaining API security and stability. Error handling and logging are critical to identifying and addressing vulnerabilities, troubleshooting issues, and gathering evidence for incident response. Let's look at some of the best practices and potential vulnerabilities to look out for:

Error Handling

When it comes to error handling, outputting the whole stack trace to the user is likely not a good idea. Most users will ignore such details, but those looking to probe further into the inner workings of a system or API will pay close attention. Error messages and stack traces can be a goldmine for bad actors and help them find weaknesses in your attack surface. To prevent this, ensure you do the following:

Prevent Information Leakage: Avoid revealing sensitive information in error messages. Provide generic error messages to users while logging detailed information for debugging purposes.
Handle Errors Gracefully: Implement error-handling middleware to catch and handle errors throughout your application. This prevents unhandled exceptions from crashing your API and provides a consistent error response format.
Custom Error Classes: Create custom error classes to categorize different types of errors and provide more informative error messages.

For example, if you are going to return an error to a user, you should make sure to only show the details that are required. Below, you can see a demonstration of this for a 500 error where the stack trace is logged to the console or another output channel, and the response is returned with only a message (and not the stack trace and other details).

Logging

Similar to error handling, getting various logic and errors captured in logs is critical for monitoring and debugging. Since logs contain a lot of sensitive info that attackers could exploit, it's important to remember these best practices when managing logs:

Log Security Events: Log all security-related events, such as login attempts, access control decisions, and input validation failures. This provides an audit trail for investigating security incidents.
Centralized Logging: Use a centralized logging system to aggregate logs from different parts of your application. This makes it easier to monitor and analyze API activity.
Log Management Tools: Consider using log management tools like ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, or Graylog to manage and analyze your logs.

Below is an example of how you could use a platform like Winston to log events. In this example, we show how a security event, such as a failed login attempt, can be written to the logs.

By implementing robust error handling and logging mechanisms, you can improve your API's security posture, troubleshoot issues effectively, and respond to security incidents promptly. Much of the error handling and logging feed into another critical aspect: API monitoring and responding to potential issues. That's exactly what we will pivot to covering next.

Monitoring and Incident Response

Continuous monitoring and a well-defined incident response plan are crucial for maintaining the security and resilience of your Node.js API. For this, you may use various agents that hook directly into your application and the infrastructure it is hosted on or use a log monitoring platform. Let's look at how monitoring and incident response work together.

Monitoring

In order to have a holistic picture of what's going on within your APIs and infrastructure, you need to put multiple levels of monitoring in place. Some log management and observability tools have monitoring built directly into them via alerting functionalities. When implementing monitoring, here are a few key value props to keep your eyes on:

Real-time Monitoring: Monitor your API for suspicious activity, such as unusual traffic patterns, login failures, and error rates. Use monitoring tools to track key metrics and receive alerts for potential security incidents.
Security Information and Event Management (SIEM): Consider using an SIEM system to collect and analyze security logs from various sources, including your API, databases, and servers. This can help identify patterns and anomalies that may indicate a security breach.
Vulnerability Scanning: Regularly scan your API for vulnerabilities using automated tools like StackHawk. This helps identify and address security weaknesses before attackers can exploit them.

Incident Response

When monitoring does pick up a potential issue, you need to move into incident response mode. For this to work seamlessly, you'll need to do the following:

Develop an Incident Response Plan: Create a detailed plan outlining the steps to take in case of a security incident. This plan should include procedures for identifying, containing, eradicating, and recovering from security breaches.
Establish Communication Channels: Define clear communication channels for reporting and escalating security incidents. This ensures that incidents are handled quickly and efficiently.
Regularly Test and Update Your Plan: Conduct regular drills and exercises to test your incident response plan and ensure that it is up-to-date and effective.

By implementing comprehensive monitoring and having a well-defined incident response plan, you can proactively detect and respond to security threats, minimizing the impact of security incidents and protecting your API and its users.

Using StackHawk to Secure Node.js APIs

As mentioned, identifying potential vulnerabilities in your APIs is critical. Although monitoring for actual breaches is a great mechanism to have in place, it is reactive versus proactive. To be proactive, you'll want to pull in StackHawk to help you actively identify all of the APIs in your attack surface using API discovery, test these APIs and remedy vulnerabilities using DAST, and provide oversight for the APIs identified and tested.

StackHawk is designed to help developers find and fix security bugs in their applications, including Node.js APIs. Here are three key features that are particularly useful for Node.js developers:

Automated Security Testing: StackHawk automates finding security vulnerabilities in your API. It tests your application for common vulnerabilities like those in the OWASP Top 10 (e.g., SQL injection attacks, cross-site scripting, broken authentication) and provides detailed reports with actionable remediation advice. This saves developers significant time and effort compared to manual testing.
Integration with CI/CD: StackHawk integrates seamlessly with popular CI/CD pipelines (e.g., Jenkins, CircleCI, GitHub Actions). This allows you to incorporate security testing into your development workflow, ensuring that vulnerabilities are identified and addressed early in the development process. This shift-left approach helps prevent security issues from making it into production.
Easy Configuration for Node.js: StackHawk is easy to configure for Node.js applications. It provides clear documentation and examples to help you get started quickly. You can configure StackHawk to scan your API endpoints, including specific headers, cookies, and request bodies, to ensure comprehensive coverage.

By using StackHawk, Node.js developers can proactively identify and fix security vulnerabilities in their APIs, reducing the risk of security breaches and ensuring the safety of their users' data.

Conclusion

Securing your Node.js API is an ongoing process that requires a proactive and comprehensive approach. You can significantly strengthen your API's security posture by implementing the strategies outlined in this article—from input validation and authentication to protecting against common attacks and securing data.

Ready to take your API security to the next level? Try StackHawk, a powerful dynamic application security testing (DAST) tool that can help you automatically identify and fix vulnerabilities in your Node.js APIs. Sign up for a free trial today and experience the difference!

Functional API Testing: A Complete Guide

StackHawk

All developers and their organizations should be heavily testing the reliability and functionality of their APIs (Application Programming Interfaces). It's a bit wild to think about just writing code with minimal testing and pushing it out to be used by API consumers. APIs are critical to almost all modern applications, so any issues with functionality not meeting users' needs are going to have a major impact on the business and customers. Although there are many types of testing that should go on in regard to APIs, API functional testing emerges as one of the most important when it comes to guaranteeing that an API is doing what it was designed to do.

Consider a distributed application architecture where microservices communicate via APIs. Each microservice exposes a set of endpoints, and the correct functioning of these endpoints is essential for the overall application's stability. A failure in any of these API interactions can cascade through the system, leading to unpredictable behavior and potentially catastrophic failures.

API functional testing addresses this by systematically verifying the behavior of APIs under various conditions and inputs. Done manually or through automation, it involves validating that APIs return the expected responses for given requests, handle errors gracefully, and maintain data integrity (in the case of CRUD operations). By testing the functionality of APIs, developers can identify and fix critical defects early in the development lifecycle, something that becomes significantly more expensive and impactful in later stages of development.

This comprehensive guide will examine the nuances of API functional testing, including the benefits and challenges. After we've covered all of the basics, we will look at four tools that provide a great place to start when implementing functional testing. Let's begin with the most fundamental question: what is API functional testing?

What is API Functional Testing?

API functional testing is a type of software testing that focuses specifically on verifying an API's functionality. This type of testing helps developers and others determine if an API meets its predefined specifications and behaves as expected under various conditions. It involves testing individual API endpoints by sending specific requests and analyzing the responses to ensure they align with the expected outcomes.

When building APIs, the input and output of them are defined as a contract. This is the interface that tells anyone who uses the API when they are required to send to the endpoint and what the endpoint will return. Functional testing works by meticulously scrutinizing this contract, ensuring the API requests and responses are in the expected format. It also works to verify that business logic is working as intended. Overall, the scope of functional testing for various aspects of the API includes:

Request methods: Verifying that the API correctly handles different HTTP methods like GET, POST, PUT, DELETE, etc.
Data formats: Ensuring the API accepts and returns data in the expected formats (e.g., JSON, XML).
Error handling: Confirming that the API returns appropriate error codes and messages for invalid requests or unexpected conditions.
Business logic: Validating that the API correctly implements the underlying business rules and processes.
Authentication and authorization: Ensuring that only authorized users can access specific API endpoints and perform certain actions.

By rigorously testing these and other aspects of API functionality, the results of this testing help developers to identify and address potential issues early in the development cycle. Of course, many other forms of testing should be going on as well, such as unit testing and security testing, but from an end-user functionality perspective, API functional testing is a key area of focus.

How does API Functional Testing work?

So, if you want to do some API functional testing, how do you get started? Chances are, if you're a developer, you're already doing some of this type of testing but without the rigidity of good practices for tracking and ensuring holistic coverage. In its simplest form, API functional testing involves a systematic process of sending requests to the API and analyzing the responses to ensure they align with the expected outcomes. Here's a breakdown of the typical workflow in five steps:

1. Define Test Cases

First, you need to figure out what you are testing and how you will test it. This is the first step to putting together your test plan. For this, you'll need to:

Identify the API endpoints: Start by clearly defining the scope of your testing. Identify all the endpoints you need to test, including their supported HTTP methods, input parameters, and expected outputs.
Formulate test scenarios: Based on the API's specifications, design test scenarios that cover various use cases and edge cases. This includes positive tests (valid inputs), negative tests (invalid inputs), and boundary tests (testing the limits of acceptable input values).

You can track this in the platform of your choice or even just create a simple spreadsheet to document the test plan and to track the execution of it.

2. Prepare Test Data:

Next, you have to create test data that will be used to call the API. At this stage, based on the test data you plan to use in the request, you may also document the expected result. Preparing this test data may involve creating mock data sets, using existing data from a database, or capturing real-time data from external sources for traffic replay or similar techniques.

3. Execute Tests:

Now, we get to the meat of the testing. At this point, we will begin to fire off API requests and get back the responses. In particular, each of these steps will look like this for each API you are testing:

Send requests to the API endpoint: Use an API testing tool or scripting language to send requests to the API endpoints with the prepared test data.
Receive and analyze responses returned: Capture the API's responses and analyze them against the expected outcomes defined in your test cases.

For each test case you execute, make sure to document all of the above so it can be used in the next step.

4. Validate Results:

With the tests executed, we now need to make sure that things are working as expected. For this, you'll need to:

Compare actual vs. expected results: Verify that the API responses match the expected status codes, headers, and data formats. Noting any discrepancies.
Assert API behavior: If you're using an automated solution, create assertions to validate specific aspects of the API's behavior, such as data integrity, error handling, and performance. If these assertions are false, the tool will tell you why the assertion failed.

5. Report and Track Defects:

The last step is when we bundle up all of the results and report any defects. Here we will:

Document test results: Record the results of your tests, including any failed assertions or unexpected behavior.
Report defects: Log any identified defects in a bug-tracking system for developers to address.

Once the developers have remedied the defect, we can start the process again for any of the failed tests. Ideally, though, you'll also do some regression testing to make sure that any of the newly fixed code won't impact any of the existing functionality that was working as expected.

Functional vs. Non-Functional Testing

While functional and non-functional testing is essential for ensuring software quality and should be part of every developer's toolkit, they focus on different aspects of the application. Understanding the distinction between these two types of testing is crucial for building a comprehensive testing strategy. Let's take a look at the differences briefly:

Although functional and non-functional testing are exclusive to each other, they are complementary. Using both types of testing is crucial for delivering high-quality software. While functional testing ensures that the application meets its functional requirements, non-functional testing ensures that it meets the desired quality standards regarding performance, security, and usability. Both are equally important.

Benefits of API Functional Testing

API functional testing offers many benefits that contribute to the overall quality and success of the software you've built. Here are some key advantages of rolling API functional testing into your API development lifecycle:

Catch Bugs Early = Saved Costs

Testing at the API level lets you catch bugs early in the development cycle, even before the UI is done. This proactive approach stops defects from moving downstream and saves you the cost and effort of fixing them later.

Truly Comprehensive Test Coverage

API functional testing lets you test the application’s core logic and functionality, which may not be accessible through the UI. This wider test coverage means the application behaves as expected across all scenarios and edge cases.

Quicker Release Cycles

API tests are generally faster to run than UI tests as they skip the overhead of rendering and interacting with the UI. If the UI changes, tests generally tend to break. This faster feedback loop lets developers iterate and deploy new API features faster.

Improved Security

Although not as comprehensive as other types of actual security testing, API functional testing can potentially expose security vulnerabilities in the API, such as authentication flaws, authorization issues, and data exposure risks.

Efficiency with Automation

Part of functional API testing can be automated and even integrated into CI/CD pipelines. This automation can reduce manual effort, improve testing efficiency, and highlight potential regression issues as soon as a pull request is created.

Better Collaboration

API functional testing promotes better collaboration between dev and test teams. By giving everyone a clear understanding of what the API should do, it helps communication and makes sure everyone is on the same page in terms of what the API should do and if the current implementation actually does it.

Language Agnostic

By testing the API functionality by interacting directly with the API, functional API testing is not language- or technology-specific. This means more flexibility in terms of which APIs can be tested and means that the people testing the APIs don't have to be familiar with the underlying code.

Functional API testing is a must-have for these exact reasons. There's no doubt about the value that good functional testing brings to the table. Of course, there are always some challenges to be aware of as well when it comes to planning and executing functional API tests.

Challenges in Functional API Testing

While API functional testing offers numerous benefits, it also presents certain challenges that testers need to overcome to ensure effective and efficient testing. Here are some common hurdles:

Lack of Comprehensive API Documentation

Clear and concise API documentation is crucial for understanding the API's functionality, input parameters, and expected outputs. However, inadequate or outdated documentation can hinder the ability to design practical test cases and interpret API responses accurately.

Handling Complex Parameter Combinations

APIs often involve numerous parameters with intricate dependencies and constraints. Testing all possible parameter combinations can be challenging, especially when dealing with large or complex APIs. Plotting out all of the different combinations manually can be a lift, but it's luckily becoming a bit easier in the age of AI.

Managing Test Data

In the same vein as the point above, generating and managing test data for various scenarios can be tough as well. This is especially true when dealing with large request and response payloads or different branches of logic within an API's business logic, all requiring different variations. Ensuring data consistency and integrity across different test cases can also be challenging, especially if working with a live database.

Testing API Dependencies

APIs often rely on other APIs or external services, creating dependencies that can complicate testing. Isolating the API under test and mocking dependencies can be challenging, especially when dealing with complex integration scenarios. Generally, this involves using additional tools to mock out the third-party API requests or database mocks.

Updating Tests for API Changes

APIs evolve over time, with new versions and updates introducing changes to functionality and parameters. Keeping API tests up-to-date with these changes can be challenging, requiring constant maintenance and refactoring of test cases to match the latest API specs and functionality.

Choosing the Right Testing Tools

As anyone in tech knows, there are many tools for everything, and functional API testing tools are no exception. Choosing tools that align with your testing needs and integrate well with your existing development environment can be tough. With a new wave of AI-enabled testing tools, this also doesn't make it any easier.

Testing for Security Vulnerabilities

Functional testing sometimes only scratches the surface of certain issues, such as ones impacting application security. Identifying security vulnerabilities in APIs, beyond very basic authentication flaws and authorization issues, requires specialized knowledge and tools. Ensuring comprehensive security testing can be challenging, especially for testers without a strong security background.

Testing Asynchronous APIs

Testing APIs that involve asynchronous operations or callbacks can be complex, as it requires handling timing issues and ensuring that responses are received and processed correctly. This makes it complex to cover all logic branches and test all error cases.

Although these challenges exist, the benefits far outweigh them. Much of the time, with a bit of research, these challenges can be easily mitigated or at least brought down to size. Next, let's figure out which tools you need to get in your hands to begin functionally testing your APIs.

Best API Functional Testing Tools

The market offers a wide array of API functional testing tools, each with its own strengths and weaknesses. Selecting the right tool depends on factors such as project requirements, team expertise, and budget constraints. Here are some of the leading API functional testing tools:

1. Postman

Postman is a popular API platform that provides a comprehensive set of features for designing, developing, testing, and documenting APIs.

Key Features:
- User-friendly interface for sending requests and analyzing responses.
- Support for various HTTP methods and data formats.
- Built-in test scripts for automating API tests.
- Collaboration features for sharing collections and workspaces.
- Integration with CI/CD pipelines.
Best For:
- Teams of all sizes, from individual developers to large enterprises.
- API testing across various stages of the development lifecycle.
- Collaboration and knowledge sharing among team members.

2. REST-assured

REST-assured is a Java library specifically designed for testing RESTful APIs.

Key Features:
- Domain-specific language (DSL) for writing expressive and readable tests.
- Seamless integration with Java development environments.
- Support for various authentication mechanisms and data formats.
- Extensive assertion capabilities for validating API responses.
Best For:
- Java developers comfortable with using libraries and frameworks.
- Testing complex API scenarios with intricate data structures.
- Integration with existing Java-based testing frameworks.

3. SoapUI

SoapUI is an open-source tool that supports both SOAP and REST API testing.

Key Features:
- Comprehensive functionality for testing various aspects of APIs.
- Drag-and-drop interface for creating and executing test cases.
- Support for data-driven testing and test automation.
- Advanced features for security and performance testing.
Best For:
- Testers who prefer a visual interface for creating and managing tests.
- Testing both SOAP and REST APIs within a single tool.
- Advanced testing scenarios requiring data-driven testing and security analysis.

4. Karate DSL

Karate DSL is an open-source framework that combines API testing, mocking, and performance testing into a single tool.

Key Features:
- Simple and expressive syntax for writing API tests.
- Built-in support for testing GraphQL APIs.
- Parallel execution for faster test runs.
- Integration with popular testing frameworks like JUnit and Cucumber.
Best For:
- Teams looking for a unified solution for API testing and mocking.
- Testing APIs with complex data structures and scenarios.
- Integrating API testing into existing CI/CD pipelines.

These are just a few examples of the many API functional testing tools available. When choosing a tool, consider factors such as ease of use, features, integration capabilities, and community support to ensure it aligns with your specific testing needs and preferences. Testing out each tool and diving into a brief proof-of-concept is likely the best way to ensure the tool fits your needs well before doing a full rollout.

Conclusion

So that’s a wrap on API functional testing! We’ve covered the what, why, and how of it and how to choose the right tools. Functional testing proves your API does what it’s supposed to, but remember, it’s only one piece of the equation. Non-functional testing (performance, security, load testing) is just as important to make sure your API can handle real-world usage and withstand threats.

Looking for security testing that fits into your functional testing workflow? Try StackHawk! StackHawk is a dynamic application security testing (DAST) tool for modern applications and APIs that is a great non-functional testing tool to combine with your functional testing efforts.

Here’s how StackHawk helps with API testing:

Automated Security Testing: StackHawk plugs into your CI/CD pipeline, runs security tests with every build, and gives you and your team instant feedback on vulnerabilities.
Full Vulnerability Coverage: StackHawk is specifically designed for APIs and can identify many vulnerabilities in the OWASP API Top 10 (as many as a DAST tool possibly can) so you can stay ahead of security risks.
API Discovery and Oversight: StackHawk goes beyond basic security scanning by adding API discovery and oversight capabilities, giving you a single pane of glass to see your API attack surface. This means you get full visibility into your API landscape, including undocumented or forgotten endpoints ("shadow APIs") that could be vulnerable to attack and may be missed by functional testing.

By combining StackHawk with your functional testing tools, you can get full API test coverage and ensure your applications are functional and secure. Ready to try it out for yourself? Sign up for a free trial today.

API Fuzzing: What It Is and How to Use It

Matt Tanner

When it comes to testing APIs, there are a lot of options out there. Generally, you won't pick a single approach; instead, you will stitch multiple types of testing together to create an API testing stack. One of these types of testing is API fuzzing or fuzz testing. In this blog, we will go over its basics and how to get started. Let's begin by understanding the key concepts within API fuzzing.

Understanding API Fuzzing

In its most simple form, API fuzzing is a security testing technique where APIs are sent a large number of malformed or unexpected input values. The hope is that through these inputs, certain vulnerabilities or issues will appear so that developers can find and fix them before attackers can. Overall, the goal of fuzzing is to make APIs and the applications they support more secure and reliable.

When developers use fuzzing, they often generate and execute API calls that contain unexpected, invalid, and random data to try and uncover potential vulnerabilities or issues. When developers test their APIs, they usually start with "happy path" tests where the outputs are known, and core application functionality is tested in a predictable way. From here, they may then branch out into some known or expected edge cases. With fuzz testing, developers are forced to go beyond the known and predictable.

API fuzzing is especially useful for:

• Detecting edge cases that could lead to crashes or unexpected behavior.

• Identifying security vulnerabilities like SQL injection, buffer overflows, and authorization bypasses.

• Stress testing API endpoints to ensure they remain stable under unexpected input conditions.

In short, fuzz testing allows developers to inundate an API endpoint with random data at high volumes to uncover security or unexpected performance issues.

Comprehensive Testing for API Endpoints

As mentioned at the beginning of the blog, comprehensive testing for API endpoints involves coupling multiple testing methods together. API fuzzing complements other testing approaches, making it possible for this type of testing to potentially uncover defects and vulnerabilities not found by other types of testing. When creating a testing stack, it's best to look at what benefits certain testing methods bring. When it comes to fuzz testing APIs, it brings the following benefits:

• Broader Coverage: Fuzzing explores a wide range of input scenarios, often beyond the imagination of developers.

• Automation-Friendly: Many fuzzing tools integrate seamlessly into CI/CD pipelines, enabling continuous testing.

• Security Focused: It is particularly adept at uncovering security flaws to address issues like injection attacks, improper input validation, and data leakage.

Based on these benefits, some good testing techniques to combine it with include the following:

• Dynamic Application Security Testing (DAST): While DAST tests APIs in runtime conditions to identify potential vulnerabilities, like insecure authentication, fuzzing digs deeper by deliberately sending malformed inputs to observe failures. Although these two can feel similar at times, DAST usually works to uncover specific vulnerabilities, whereas fuzzing can also uncover bugs, crashes, or other instability issues that might not pose any immediate security threat.

• Unit and Integration Testing: These types of static tests work to ensure application functionality works as expected. Fuzzing extends this by challenging input validity assumptions and scenarios outside the predictable and "happy path."

• Load Testing: In some cases, load and stress testing can incorporate fuzzing to simulate chaotic input scenarios under heavy load. Combining the two can give you a similar output to chaos testing.

These aren't the only testing methods that work well with fuzzing, but you get the idea: combining various methods together helps to create a more holistic testing strategy. So, how would you go about bringing fuzz testing into your toolkit? Let's look at that next.

Fuzz Testing Techniques and Tools

In this section, we will briefly look at specific fuzz testing techniques and the tools you can use to implement these techniques. First, let's look at techniques.

Fuzz Testing Techniques

Although there are probably numerous variants of fuzz testing techniques, three stand out as some of the most popular. These include:

Swarm Testing

This technique rapidly sends diverse and randomized inputs to your API endpoints, mimicking unpredictable real-world scenarios to uncover bugs and performance bottlenecks. When people imagine fuzz testing in their heads, this is usually the default technique that comes to mind.

Schema Fuzzing

More specific to APIs, schema fuzzing uses API specifications, such as OpenAPI or JSON Schema, to generate test cases that align with or deliberately violate expected input structures. This technique is a little more pointed than swarm testing APIs.

Stateful REST API Fuzzing

If APIs require stateful testing or are part of a workflow (multiple API calls that are called in succession to complete a task), stateful REST API fuzzing can be used. This technique tests APIs in the context of their operational state by executing sequences of API calls to identify issues in workflows or dependencies.

Popular Fuzz Testing Tools

Now that you know some of the techniques, you can begin to explore the tools. Just like any testing, there's a massive abundance of tools that can help developers implement fuzz testing within their testing stack. Here are three that will give you a good place to start:

RESTler

Developed by Microsoft, RESTler is an open-source, extensible framework for fuzzing RESTful APIs. This API Fuzzer is particularly good at stateful API fuzzing and understanding the relationships between different API calls. RESTler excels at finding complex bugs that surface through sequences of API calls (e.g., authentication flaws and authorization issues in multi-step processes).

Key Highlights:
- Learns API request sequences from OpenAPI specifications.
- Generates and executes tests based on learned API behavior.
- Provides detailed bug reports with reproduction steps.

Radamsa

This tool is a general-purpose fuzzer known for its speed and simplicity. While not API-specific, it can be used to generate invalid or unexpected data that you then feed into your API requests. Radamsa is excellent for basic swarm testing, where you want to throw a large volume of randomized, invalid inputs at your API to see what breaks. It's less specialized than RESTler but can be very effective for raw fuzzing power.

Key Highlights:
- Lightweight and fast.
- Supports a wide range of file formats and data types.
- Highly configurable mutation engine.

Fuzzapi

Fuzzapi is a Python-based API fuzzing tool designed for ease of use. It allows you to define fuzzing targets and mutation strategies in a simple YAML format. Fuzzapi is a good choice for teams looking for a straightforward way to incorporate fuzzing into their testing process. It supports both schema fuzzing and swarm testing, providing flexibility in approaching your fuzzing strategy.

Key Highlights

Simple setup and configuration.
Supports various fuzzing methods (e.g., mutation, generation).
Integrates well with CI/CD pipelines.

Best Practices for API Fuzzing

For those implementing fuzz testing as part of their testing and development process, there are a few best practices to be aware of. These best practices include:

Define Clear Objectives For Your Tests

Understand whether you are testing for functional bugs, security vulnerabilities, or performance issues. Knowing why you are testing can help to keep tests targeted and allow results to be interpreted in context.

Use Your API Docs To Lead The Way

When it comes to kicking off testing, use OpenAPI documentation or other formats, if applicable, to generate meaningful test cases. By referencing these docs, you'll know exactly what each API request should look like and the corresponding fields in the response, such as a status code or expected headers.

Automate and Integrate

Although fuzzing tools can be run locally, automated test execution can be incorporated into CI/CD pipelines for continuous testing and test reliability. Making pull requests automatically kick off a fuzz testing job and report as part of your pipeline is a great way to make sure that all developers are in the know and that all code is covered.

Prioritize Endpoints

If you have a large portfolio of API endpoints, identify your most critical place to begin implementation. Focus on high-risk endpoints handling sensitive data or performing critical operations, as these should be put under test as a priority. Eventually, roll out test coverage more holistically but ensure that critical endpoints and the code within them are covered via your fuzz testing efforts.

Analyze Results

Don't blindly follow the reports of your fuzz testing efforts since not all issues will be of the same weight. Fuzzing can produce a lot of noise; prioritize issues based on exploitability and impact.

With these best practices in place, you'll be on a good path toward efficiently implementing fuzz testing for your APIs.

Conclusion

With that, you're now familiar with API fuzzing and ready to try it out for yourself. Remember to keep the various types of fuzz testing in mind as you move forward, consider automated tools to make testing easier, and always follow the best practices we discussed. Of course, for those who want to augment their testing beyond simply fuzz testing, StackHawk's DAST platform can help in multiple ways.

First, StackHawk's DAST platform can augment your fuzzing efforts through its DAST tool, specifically designed to help you find and fix many vulnerabilities in the OWASP API Top Ten. This can help to confirm if bugs found during the fuzz testing process are exploitable security vulnerabilities.

On top of this, StackHawk also offers API Discovery and Oversight. API discovery can help to ensure that every API in your codebase is accounted for and brought under test for both DAST and API fuzzing. Oversight allows you to see your entire attack surface under a single pane of glass, making security operations more straightforward to manage and track.

Want to try out StackHawk for yourself today? Sign up for a free trial and combine the best DAST for APIs with the power of API fuzz testing that we covered in this blog.

Maximize Security with GitHub Advanced Security and DAST: What It Is and How to Use It

StackHawk

When developers are trying to ship the latest feature or fix, security can often feel like an unwelcome bottleneck. Balancing rapid innovation with good security practices is a challenge every developer faces. But what if security could keep pace with development velocity, seamlessly integrate into your workflow, and empower you to bake security directly into every piece of your application?

If you're a GitHub user, you've likely come across GitHub's solution to this: GitHub Advanced Security. This suite of security tools is designed to shift security left and make it an integral part of your development process from right within GitHub. With features like code scanning, secret scanning, and dependency review, GitHub Advanced Security helps you identify and address vulnerabilities early in the development lifecycle before they become bigger issues in production.

You can also integrate Dynamic Application Security Testing (DAST) into your GitHub workflow to augment what GitHub Advanced Security offers. DAST allows you to test your running applications for vulnerabilities, providing a real-world perspective on the security risks present inside your application that could be exploited at runtime.

In this blog, we'll explore the key features of GitHub Advanced Security, delve into the benefits of DAST, and demonstrate how these powerful tools can help you build more secure applications faster. We'll also show you how to amplify your security efforts by combining GitHub Advanced Security with StackHawk. Let's begin by doing a brief primer on security vulnerabilities.

Security Vulnerabilities: Understanding the Risks

Security vulnerabilities are weaknesses in your code that attackers can exploit. Vulnerabilities themselves come in all shapes and sizes, with varying levels of severity and impact. If exploited, these weaknesses can lead to big problems like data breaches, financial loss, and damage to your company reputation.

Some common types of security vulnerabilities you've likely heard of include:

SQL Injection: When an attacker injects malicious code into your app to access or manipulate your database.
Cross-Site Scripting (XSS): Attackers inject malicious scripts into your web pages, to steal user data or hijack user sessions. Attackers can then impersonate your users and do actions on their behalf.
Cross-Site Request Forgery (CSRF): Tricking users into doing unwanted actions on your website, like changing their password or making a purchase, by exploiting the trust your website has in a user’s browser.
Remote Code Execution (RCE): Vulnerabilities that allow attackers to execute code remotely on your system. This can happen due to misconfigured systems or handling of untrusted data, especially with XML sources, which is a critical security risk.

Understanding every vulnerability type, how it appears in your code base, and whether it can be exploited is really tough to do. Luckily, unlike developers in the past, there's been a lot of automation added to the developers' toolkit to help with this.

As an automated set of tools, this is where GitHub Advanced Security comes in. It helps you find vulnerabilities in your code, prioritize them by severity, and provides guidance on how to fix them. By integrating security checks into your development workflow, you can prevent these vulnerabilities from being introduced into production code (without knowing how to find and fix every vulnerability manually) and build more secure applications.

What is GitHub Advanced Security?

GitHub Advanced Security is an extensive offering when it comes to tooling to build secure software. It’s a comprehensive suite of features baked into GitHub that integrate seamlessly with your development workflow. Using the various features can help you identify and address security vulnerabilities throughout the software development lifecycle and truly focuses on the shift-left methodology of finding everything as early as possible.

Of course, there are tons of security products out there but here’s what sets GitHub Advanced Security apart:

Proactive Vulnerability Detection: Instead of reacting to security issues after they surfaced, GitHub Advanced Security helps you proactively find and mitigate security vulnerabilities before they reach production. This shift-left approach saves you time, money, and headaches in the long run.
Seamless Integration: GitHub Advanced Security is built directly into the GitHub platform, meaning you don’t have to juggle separate tools or disrupt your existing workflows. It’s security that works the way you do, right from within GitHub.
Comprehensive Coverage: GitHub Advanced Security provides a wide range of security capabilities to address various aspects of application security. It’s a one-stop shop for securing your codebase with tools to cover many of the most important angles.
Automation for Efficiency: Many features within GitHub Advanced Security are automated, allowing you to streamline your security processes and focus on what matters most: building great software while automation takes care of the rest.

By integrating these powerful features into your development process, GitHub Advanced Security gives developers a better way to build secure software without sacrificing speed or agility.

Using GitHub Advanced Security

Want to start using GitHub Advanced Security? Getting started with GitHub Advanced Security is surprisingly easy. It's designed to integrate seamlessly with your existing GitHub workflow so you can enhance your security posture without disrupting the development processes you've already come to build and love within GitHub.

Here's how you can start leveraging GitHub Advanced Security:

1. Enable GitHub Advanced Security:

If you're using GitHub Enterprise Cloud, you can enable GitHub Advanced Security at the organization or repository level.
For GitHub Enterprise Server, you'll need to install the Advanced Security license on your instance.

2. Configure the features you need:

Code scanning: Choose the languages and query suites you want to use to analyze your code. You can also customize the frequency of scans and configure alerts based on severity levels.
Secret scanning: Enable secret scanning alerts to detect leaked credentials and prevent new secrets from entering your codebase.
Dependency review: Configure dependency review to get alerts about vulnerable dependencies and automatically generate pull requests to update them.

3. Integrate with your workflow:

GitHub Actions: Use GitHub Actions to automate security checks and integrate them into your CI/CD pipeline. For example, you can trigger code scanning on every pull request to ensure that new code changes don't introduce vulnerabilities.
GitHub Apps: Extend the functionality of GitHub Advanced Security with GitHub Apps. Several security-focused apps can enhance your security posture, such as those that provide vulnerability management or security reporting.

4. Monitor and respond to alerts:

Regularly review your security alerts and prioritize them based on their severity.
Use the information in the alerts to understand the vulnerabilities and take appropriate action to remediate them.
Collaborate with your team to address security issues and improve your overall security posture.

By following these steps to get set up with GitHub Advanced Security, you can significantly enhance the security of your code and reduce the risk of security breaches. With the number of features GitHub Advanced Security offers, we should briefly cover some of the key highlights before looking at the platform's best practices.

Code Scanning and Code Scanning Alerts: Find and Fix Vulnerabilities Fast

Powered by the CodeQL engine, GitHub's code scanning analysis goes beyond basic checks to deeply analyze your code and identify a wide range of security flaws, like SQL injection and cross-site scripting (XSS). Here is how the CodeQL engine works to identify vulnerabilities it can statically detect in the code:

Analyze: CodeQL analyzes your codebase to understand how data flows through your application when you push code.
Identify: CodeQL uses a vast database of queries to pinpoint common security vulnerabilities.
Alert: When a potential vulnerability is found, you get a detailed alert with information about the issue, its location, and its severity.
Remediate: Code scanning guides developers on how to fix the identified vulnerabilities.

With this type of scan, developers and organizations get quite a few advantages. Here are the three most important to highlight:

Early detection: Find and fix vulnerabilities and code errors that can impact security before they reach production.
Reduced costs: Addressing vulnerabilities early is significantly cheaper than fixing them later in the development process.
Improved code quality: Write cleaner, more robust code.

Another neat part of CodeQL is adding the extension directly to VS Code. With the extension, you can query the code directly in your VS Code instance to identify and remedy any vulnerabilities before you commit them.

Compliance and Integrations: Seamless Security for Your Ecosystem

GitHub Advanced Security isn't just about finding and fixing vulnerabilities; it's also about building a secure development ecosystem that aligns with industry standards and integrates seamlessly with your existing tools.

When it comes to compliance, meeting compliance requirements can be a complex and time-consuming process. By using GitHub Advanced Security, developers can easily access tools that can help them meet various industry standards and regulations, including:

HIPAA: Protect sensitive patient health information with features like secret and code scanning to identify and mitigate potential vulnerabilities that could lead to data breaches.
PCI DSS: Secure credit card data and comply with PCI DSS requirements by leveraging secret scanning to detect and protect sensitive cardholder information.
GDPR: Meet GDPR requirements for data privacy and protection by using features like code scanning and secret scanning to identify and address potential vulnerabilities that could expose personal data.

Of course, it also helps when tools easily integrate with the tools and processes you already use. For this, GitHub Advanced Security is designed to work seamlessly with other GitHub features and tools for a super-refined workflow. For those already in the GitHub ecosystem, Advanced Security works well with:

GitHub Actions: Automate your security checks by integrating code scanning, secret scanning, and dependency review into your GitHub Actions workflows. This allows you to automatically trigger security scans on every pull request or code change.
GitHub Apps: Extend the functionality of GitHub Advanced Security with security-focused GitHub Apps. These apps can provide additional security capabilities, such as vulnerability management, security reporting, and integration with other security tools.
GitHub Enterprise Cloud: Leverage the power of GitHub Enterprise Cloud to enhance your security posture. GitHub Enterprise Cloud offers advanced security features and controls, including SAML single sign-on, access control, and audit logging.

Best Practices for Using GitHub Advanced Security

As with adopting any new tool, it makes sense to understand the best practices. With such a wide array of tools available within the platform, to get the most out of GitHub Advanced Security, here are a few best practices to follow:

Enable code scanning: Code scanning is a feature that scans code for security issues as it is written. Enable code scanning for your repository to identify potential vulnerabilities early on.
Use CodeQL: CodeQL is a code analysis engine developed by GitHub to automate security checks and also add the extension to VS Code. Use CodeQL to identify vulnerabilities in your code and prevent developers from introducing new problems.
Configure alerts: Configure alerts to notify you of potential security vulnerabilities in your code. This will help you stay on top of security issues and address them before they become major problems.
Use secret scanning: Secret scanning is a feature that identifies secrets, such as API keys and access tokens, in your code. Use secret scanning to prevent sensitive information from being exposed when developers accidentally commit it into a repo.
Integrate with DAST tools: Integrate GitHub Advanced Security with DAST tools to provide a comprehensive security testing strategy that covers static and dynamic analysis of your codebase.

Using GitHub Advanced Security with DAST

Although GitHub Advanced Security offers many features to keep code secure, it's even better when used with Dynamic Application Security Testing (DAST) tools. DAST tools simulate real-world attacks on a web application, identifying vulnerabilities that attackers can actually exploit. This gives developers a view into vulnerabilities that can truly be exploited instead of false positives often found through static code analysis. By integrating GitHub Advanced Security with DAST tools, developers can holistically identify security vulnerabilities in their code and address them before they reach production.

What is DAST?

A core component of any AppSec stack, Dynamic Application Security Testing (DAST) platforms analyze your running application to find security vulnerabilities. Unlike static analysis, which examines your code, DAST interacts with your application like a real user or attacker would. This allows these tests to discover vulnerabilities that might only be present when the application is running, such as those related to authentication, authorization, server configuration, or dynamic behavior.

DAST tools like StackHawk test your APIs and applications by simulating attacks against them and analyzing the responses to identify potential security weaknesses. This provides a more accurate picture of your application's security posture in a real-world environment. By incorporating DAST, you can uncover vulnerabilities that platforms like GitHub Advanced Security might miss. The result is a comprehensive testing and security stack that can help you gain confidence in your application's defenses and proactively protect against potential breaches.

Level Up Your AppSec: Combining StackHawk and GitHub Advanced Security

While GitHub Advanced Security provides a great foundation for developing secure applications and APIS, integrating a Dynamic Application Security Testing (DAST) solution like StackHawk can further elevate your AppSec program.

As GitHub's preferred DAST partner, here's how StackHawk complements GitHub Advanced Security:

Uncovers runtime vulnerabilities: StackHawk excels at finding vulnerabilities that might not be apparent in static code analysis, such as those related to authentication, authorization, server configuration, and the dynamic behavior of your application.
Tests in a real-world environment: Unlike static analysis, which examines code in isolation, StackHawk tests your application in its running state, providing a more accurate picture of your actual security posture and reducing false positive results.
Seamless CI/CD integration: StackHawk is built for automation in CI/CD, just like GitHub Actions. This allows you to seamlessly integrate security testing into your development pipeline, ensuring that vulnerabilities are caught early and often.
Actionable insights and remediation: StackHawk goes beyond simply identifying vulnerabilities. It provides detailed reports with clear, actionable remediation guidance, making it easy for developers to understand and fix security issues efficiently.
Built for modern applications: StackHawk is designed with modern architectures in mind, making it ideal for testing APIs and microservices. It can effectively find and fix security bugs in these complex environments, where traditional security tools often struggle.

To start with StackHawk today, sign up for a 14-day free trial and combine it with GitHub Advanced Security for a best-in-class security stack. When combining GitHub Advanced Security and DAST, there's no better companion than StackHawk.

Using Postman for Testing API Endpoints: A Practical Guide for Functional API Testing

Matt Tanner

APIs are essential to modern software, allowing applications to communicate and exchange data. As we use APIs more, making sure they are reliable, fast, and secure is very important. Choosing the right API testing tool can significantly help your testing strategy.

This guide is a practical resource on using Postman as a functional API testing tool. Whether you're experienced with APIs or just starting out, this blog will give you the knowledge and practical skills to use Postman's powerful features for thorough API testing.

Introduction to API Testing

Before jumping into Postman, let's first establish a solid understanding of what API testing is. At its core, API testing ensures the functionality, reliability, performance, and security of an Application Programming Interface, or API. Unlike UI testing, which focuses on the user interface, API testing directly examines the underlying communication layer between the applications themselves by sending multiple requests to API endpoints and validating the responses.

By concentrating on the core logic and data exchange layer, developers can practice API security testing and enable early issue detection and resolution within the development lifecycle. This approach prevents regressions and guarantees seamless integration among software components.

Why is API Testing Important?

Having developers perform API testing is crucial for creating solid and reliable apps. Testing APIs in a dedicated testing environment lets developers find and fix bugs early, minimizing potential issues later on. This method enhances test coverage, addressing more scenarios and edge cases than UI tests.

API tests enable faster development cycles and quicker feedback, speeding up release times. This testing lowers costs, enhances security by finding vulnerabilities, and boosts software quality, improving system performance. API testing is key to the software development lifecycle (SDLC), ensuring APIs meet functionality, reliability, and security requirements.

API testing also unlocks an understanding of how your API handles a wide variety of fail states and successful interactions. Load testing reveals how your API handles increased traffic. Contract testing can help ensure that systems are doing what they should be doing, regardless of traffic volume or intent. Effective testing uncovers security vulnerabilities, highlighting potential issues at scale, including external service validation and early detection. The benefits are extensive, from regression tests and beyond!

Effective API testing requires a deep understanding of the API's purpose, expected behavior, and underlying technologies. By combining manual testing and test automation, developers can build robust, reliable, and secure APIs that seamlessly integrate with other software components at scale.

Getting Started with Postman

Postman is a versatile API platform that streamlines API lifecycle management with tools for building, testing, documenting, and sharing. Its ease of use and extensive capabilities make it a favorite among developers for various use cases and deployments.

Here's how to get started:

Download and Installation

Visit the official Postman website to download the appropriate version for your operating system, be it Windows, macOS, or Linux.
Follow the on-screen instructions to install Postman on your machine.

Creating a Postman Account

Using Postman without an account is possible, but creating one offers extra features such as workspace syncing, team collaboration, and access to the Postman API Network. Simply follow the prompts to create an account with accurate contact details for verification.

After account creation, you can start using the application.

Exploring the Postman Interface

Before using Postman, familiarize yourself with the key components in the Postman interface:

Workspace: This is the main area where you organize your API requests and collections.
Sidebar: The sidebar provides access to workspaces, history, collections, and APIs.
Request Builder: This is the central area where you compose your API requests, including the URL, method, headers, and body.
Response Viewer: This area displays the API response, including the status code, headers, and body.

Organizing and Running API Tests in Postman

Postman offers robust features to organize and run your API testing process efficiently.

Let's explore how to structure and write tests to maximize effectiveness.

Collections

Collections allow you to organize related API requests into folders and manage their execution sequence. Think of collections as test suites for your APIs - by grouping related requests, you can easily run tests for specific application functionalities or modules.

To further organize your tests, create folders within collections. This allows for a hierarchical structure, enabling you to categorize requests by functionality, endpoint, or any other relevant criteria.

Variables

Postman supports environment variables, global variables, and collection variables. Using variables makes your tests more flexible and maintainable, unlocking more observability and eliminating testing rigidity that might generate false data or make testing difficult at scale. For instance, you can store base URLs, API keys, and authentication tokens as variables, allowing you to easily switch between different environments (e.g., development, staging, production) without modifying your requests.

Collection Runner

The Collection Runner is a powerful tool for executing a series of API requests in a defined sequence. This facilitates automated API testing, enabling single-click test suite execution, running tests across collections or specific folders, customizable iterations for test versioning, and setting request delays. The Collection Runner provides detailed test results for each API request, including pass/fail status, response times, and error messages.

Data-Driven Testing with CSV and JSON Files

Postman allows you to import data from CSV or JSON files for data-driven testing, which allows you to run the same requests with different sets of data, increasing test coverage and efficiency. This allows you to test various scenarios and edge cases without manually modifying each request.

You can create well-structured, maintainable, and comprehensive API tests in Postman using these features. This structured approach improves the efficiency of your API testing process and enhances the reliability and accuracy of your API test results.

Writing Effective Test Scripts in Postman

Writing tests in JavaScript allows for a comprehensive suite that rigorously tests your API's functionality. The key to this process is to understand the pm object - through the pm object, you can access request details like URLs, headers, and body content and retrieve response information such as status codes, headers, and the response body itself.

To structure your tests effectively, you can leverage the pm.test() function. This function will let you define individual test cases with descriptive names, making your test output clear and informative. Within each test case, employ the ChaiJS BDD syntax for expressive assertions, which will ensure that your code is readable and easy to understand. For instance, you can easily assert that the response status code is 200 using pm.response.to.have.status(200), or that the response body contains specific data using pm.expect(jsonData.name).to.equal("John Doe").

When dealing with asynchronous operations, use pm.sendRequest() function and embrace promises or async/await for clean and efficient code handling. Your tests can become more adaptable by storing and reusing values across requests with dynamic variables. This is particularly valuable for elements like authentication tokens, base URLs, and test data, which might change across different environments or test scenarios.

You can also combine Postman's data import functionality within your scripts to run the same tests against various datasets, which will significantly expand the coverage of your test API. To streamline this workflow and promote consistency, you can also create reusable functions or snippets for common test scenarios, minimizing code duplication and ensuring uniformity across your tests. By employing these methods, you can transform your Postman tests into detailed evaluations that not only validate but also significantly improve the functionality, reliability, and overall API performance.

Advanced Postman Features for API Testing Process

To take this a step further, you can use a series of advanced offerings provided by Postman to unlock additional testing options.

Pre-request Scripts

Pre-request scripts in Postman enable you to execute JavaScript code before a request is sent. This capability allows for dynamic request modification, data setup, and other actions.

For instance, you can generate timestamps or unique IDs to include in your requests, ensuring that each request is distinct and trackable throughout the testing environment. You can take this a step further and set dynamic headers based on environment variables, allowing you to switch these tests seamlessly between different testing environments.

Pre-request scripts also allow you to fetch data from external sources and incorporate it into your request. This can help formulate tests that would require third party data sources or other workflows which would be called as part of the pre-request service method rather than as a result of a specific request.

Post-request Scripts

Post-request scripts in Postman are executed after receiving a response from the API. Primarily for writing test assertions, their special attributes extend their utility beyond basic validation.

Specifically, these scripts allow you to extract data from the response, which can then be used in subsequent requests, enabling dynamic workflows. You can also store data in environment or global variables for later use, facilitating data persistence across requests, or port data from request to request in a chain, allowing for very complex request flows that might utilize multiple internal pathways. To take this a step further, post-request scripts can be used to trigger entire new workflows, or even send notifications based on the response, allowing you to test notification systems or automated workflows.

Working with Cookies

Cookies are small text files that websites store on a user's computer to remember information about them, such as login details or preferences. These are often very important in web application interactions, and as such, should be included in certain testing approaches.

Postman provides robust tools for managing cookies, allowing you to simulate various user scenarios and thoroughly test how your API would interact with them. You can easily inspect the cookies exchanged between your requests and the API, giving you valuable insight into session management and user tracking.

Furthermore, Postman allows you to modify or even delete cookies, enabling you to test how your API behaves under different cookie conditions, such as expired sessions or altered user preferences. This granular control over cookies ensures comprehensive testing of how your API handles cookies.

Authorization Helpers

Postman simplifies working with various authentication methods, providing built-in helpers to streamline the process of securing your API requests. Whether you're using basic authentication with username and password credentials, API keys for simpler authorization, OAuth 1.0/2.0 for delegated access, or bearer tokens for token-based authentication, Postman has you covered. These built-in helpers assist in generating and managing the necessary authorization headers, making it easier to test APIs that require secure access.

This dramatically simplifies the often complex process of authenticating requests, allowing you to focus on testing the core API development.

The Collection Runner and Newman

The Collection Runner unlocks advanced API testing in Postman. It allows you to execute a collection of requests sequentially, using data files (CSV or JSON) to test various scenarios with different inputs. You can even schedule collections to run at specific intervals, automatically monitoring your APIs for regressions or performance issues over time.

For more advanced automation, Newman, Postman's command-line interface, lets you run collections from your terminal or integrate them into your CI/CD pipeline. This provides greater flexibility, allowing you to customize collection runs, generate reports in various formats, and easily integrate with other tools in your development workflow.

Integrating with CI/CD

To achieve continuous testing and ensure your APIs are always thoroughly vetted, integrate your Postman tests directly into your CI/CD pipeline. This automates testing, catching any issues early with every code change. Postman readily integrates with popular CI/CD tools like Jenkins, Travis CI, and CircleCI, making incorporating API testing into your existing workflows easy.

By automating your API tests with Postman, you can create a robust testing framework that helps you confidently deliver high-quality APIs.

Introductory Postman Demo

Below is an example of a simple Node.js API. This API allows users to perform basic CRUD operations that will allow us to demonstrate the basics of testing an API with Postman.

To run this app, first, ensure you have Node.js installed. Then, create a new directory for your project, ours is named “postman-testing-api-example”, and initialize the directory by running:

You'll also need to install Express, a popular web framework for Node.js, and a few other dependencies we will use in the project. You’ll do this by running the following npm command:

npm install express sqlite3

Now, in the root of the project we just created, create a file named server.js and add the following code:

const express = require('express');

const app = express();

const port = 3000;

const sqlite3 = require('sqlite3').verbose();

app.use(express.json());

// Initialize the database

const db = new sqlite3.Database(':memory:');

db.serialize(() => {

db.run(`CREATE TABLE IF NOT EXISTS users (

id INTEGER PRIMARY KEY AUTOINCREMENT,

name TEXT NOT NULL

)`);

// Insert initial sample data

db.run(`INSERT INTO users (name) VALUES ('Alice'), ('Bob')`);

});

// GET /users - Retrieve all users

app.get('/users', (req, res) => {

db.all('SELECT * FROM users', [], (err, rows) => {

if (err) {

res.status(500).json({ error: err.message });

return;

}

res.json(rows);

});

// GET /users/:id - Retrieve a user by ID

app.get('/users/:id', (req, res) => {

const id = parseInt(req.params.id);

db.get('SELECT * FROM users WHERE id = ?', [id], (err, row) => {

if (err) {

res.status(500).json({ error: err.message });

return;

}

if (!row) {

res.status(404).send('User not found');

return;

}

res.json(row);

});

// POST /users - Create a new user

app.post('/users', (req, res) => {

const { name } = req.body;

if (!name) {

res.status(400).json({ error: 'Name is required' });

return;

}

db.run('INSERT INTO users (name) VALUES (?)', [name], function (err) {

if (err) {

res.status(500).json({ error: err.message });

return;

}

res.status(201).json({ id: this.lastID, name });

});

// PUT /users/:id - Update an existing user

app.put('/users/:id', (req, res) => {

const id = parseInt(req.params.id);

const { name } = req.body;

if (!name) {

res.status(400).json({ error: 'Name is required' });

return;

}

db.run('UPDATE users SET name = ? WHERE id = ?', [name, id], function (err) {

if (err) {

res.status(500).json({ error: err.message });

return;

}

if (this.changes === 0) {

res.status(404).send('User not found');

return;

}

res.json({ id, name });

});

// DELETE /users/:id - Delete a user

app.delete('/users/:id', (req, res) => {

const id = parseInt(req.params.id);

db.run('DELETE FROM users WHERE id = ?', [id], function (err) {

if (err) {

res.status(500).json({ error: err.message });

return;

}

if (this.changes === 0) {

res.status(404).send('User not found');

return;

}

res.status(204).send();

});

// Start the server

app.listen(port, () => {

console.log(`API server is running at http://localhost:${port}`);

});

Create a Web Server

Here’s a quick code breakdown demonstrating how to create a simple web server using Node.js, Express.js, and SQLite3. This code provides a REST API for accessing and modifying user information stored in an SQLite database, running in memory for simplicity and demonstration purposes. Here's a detailed look at the key components and actions within the code:

Initialization of Express App:
- The code begins with initializing an Express application (const app = express();).
SQLite Database Setup:
- A SQLite database is initialized in memory (const db = new sqlite3.Database(':memory:');), making it temporary and ideal for demonstrations without external database connections.
- Inside db.serialize(...), a table named users is created, and two example user records are inserted, setting up initial data.
API Endpoint Definitions:
- Basic CRUD endpoints are created to demonstrate accessing the API from Postman.
Server Initialization:
- Finally, the application listens to incoming requests on a specified port (const PORT = 3000;), making the API accessible to clients. A console log message confirms the server's successful launch.

Run the Code

Now that our code is complete, it’s time to run the application and bring up our API. To run your API, run the following command in a terminal targeting the root of your project:

node server.js

Now that the API is running on http://localhost:3000, the next steps will show you how to test your API using Postman.

Test the API

Before testing anything, we need to create a collection. Select the Collections tab on the left side, click the plus icon to add a new collection, and choose Blank Collection.

To test our API, launch Postman and create a new request. We’ll start with the GET /users endpoint. Click on the New button at the top of the Postman app, then select HTTP Request from the dropdown. This opens a new tab where we can configure our request.

By default, it is configured for a GET request, so all we need to do now is enter our URL in the URL field, enter http://localhost:3000/users. This is the endpoint we set up in our API to return the list of users. Click the blue Send button on the right side of the URL bar and Postman will send an HTTP GET request to your API’s /users endpoint and display the response in the lower half of the screen.

If all works well, you'll see a JSON-formatted user list, similar to the above screenshot.

Next, let's create a POST request, following the same steps as before but selecting POST from the dropdown. Use the same URL http://localhost:3000/users, but add a request body. Click the Body tab, select raw, choose JSON from the right dropdown, and enter your JSON payload.

The remaining requests will be:

GET http://localhost:3000/users/{{userId}}
PUT http://localhost:3000/users/{{userId}}
- With a body of { "name": "Charles" }
DELETE http://localhost:3000/users/{{userId}}

After creating the requests, save them to the earlier collection using the Save button above the Send button.

Advanced Postman Functionalities

To access advanced features, create an environment by clicking the Environment tab on the left, then "Create Environment." After creation, select it from the dropdown in the upper right corner.

With a collection and environment created, the next step is to go to the scripts tab of the POST method and add the following code. This code will set an environment variable to the Id of the added user.

let responseData = pm.response.json();

pm.environment.set("userId", responseData.id);

Click the three dots beside the collection name and choose "Run Collection." You can arrange the requests as desired. To show a user being added, updated, and deleted in one run, order them as shown below. Check "Persist responses for a session" to view responses. Then, click "Run Users" to start.

After running the collection, the "Run Results" tab will open, providing a high-level overview of the results.

In the results tab, drill into a request to see the exact response. For example, the GET request returns the newly created user.

If you click "Run Again" and check the GET request's response, you'll notice the user's ID has increased due to the script set up in the earlier POST request.

Beyond Functionality: Ensuring Your APIs are Securely Built

Using Postman for API testing can ensure that your APIs function correctly. However, are you sure they're secure against threats? Can you ensure they're safeguarded from security vulnerabilities that might expose sensitive data or disrupt your services?

Traditional testing strategies often overlook critical security weaknesses. This is where StackHawk excels. As a Dynamic Application Security Testing (DAST) solution, StackHawk is purpose-built to identify and help remediate API vulnerabilities. It seamlessly integrates within your CI/CD pipeline to help automate API tests as part of a holistic API testing strategy, continuously assessing your APIs for potential risks.

Achieve Comprehensive API Security with Automated Discovery

In addition to automated testing, StackHawk provides a powerful API discovery engine and API oversight, features that allow you to see your complete API attack surface. This functionality automatically identifies and documents all your API endpoints, including those that might be inadvertently missed. This comprehensive mapping of your API development process landscape ensures that every API endpoint undergoes rigorous security assessment, leaving no gaps in your security posture. Sign up today to try Stackhawk for yourself to move beyond functional API testing and into the next stage of API security testing.

December Product Updates

Brian Erickson

As the holidays approach, we’re wrapping up the year with some exciting updates to make your security testing with StackHawk smoother, smarter, and faster. From Oversight for better application management to new API capabilities and the latest HawkScan improvements, this release is packed with gifts for your team.

Let’s dive into what’s new! 🎅✨

Oversight: Simplified Security Management

As the number of applications under test grows, keeping track of security testing can become overwhelming. That’s where Oversight comes in. With a streamlined view of your applications and their security status across environments, you can easily manage testing efforts at scale. Use the new app list with filters to quickly find what you need, and explore detailed app insights to maintain a strong security posture.

API Discovery: See Your Attack Surface Like Never Before

Understanding your APIs just got easier. The new Attack Surface Report gives you a high-level summary of your API exposure, while detailed repo views include AI-powered insights, topics, and languages to help prioritize testing. Plus, the new “Repos Added” card keeps you up to date on newly discovered repositories in your attack surface.

Platform Updates: Better Collaboration and Reporting

Make sharing and collaboration easier than ever with these updates:

PDF Scan Reports: Create polished, shareable reports that are perfect for keeping stakeholders informed.
Comment on Findings: Your team can now leave comments directly on findings without changing their triage status, streamlining communication between developers and security teams to resolve issues faster.

Scan Performance: Unlock Faster, More Accurate Scans

The key to effective security testing in CI/CD is fast, efficient scans. After working with many customers to tune their scans, we’ve seen how diagnosing application and network performance can dramatically improve scan speeds and reduce false positives.

With the new Scan Performance feature, you can now view detailed application performance metrics directly in the Scan Details screen. This includes:

Response Duration: See how quickly your application responds to requests.
Status Codes: Understand the HTTP status codes returned by your application.

New API Capabilities: Greater Flexibility and Control

Our latest API updates give you more power to automate and scale your application security program:

Application and Environment v2: Robust filtering and additional context make it easier to manage your apps and environments.
Scan Alert Details: Access detailed insights into scan findings to help your team prioritize and resolve issues faster.
Scan Deletion: Programmatically clean up your scan history for better organization and efficiency.

HawkScan 4.2 + 4.3: Smarter, Faster Scans

With the latest HawkScan updates, you’ll see improvements across the board:

Log Cleanup and Error Handling: Cleaner logs and smarter error messaging to reduce friction.
Performance Boosts and Bug Fixes: Faster scans and fixes for proxy configuration and plugin commands.
Smarter gRPC and OpenAPI Scanning: Improved support for gRPC input vectors and single-path OpenAPI specs.
SOAP WSDL Improvements: Better handling of linked files for seamless SOAP testing.

Check out the change log and upgrade to the latest version from our downloads page and enjoy a faster, more reliable scanning experience.

Read more (link out to call to actions or additional resources (docs, website, etc):

Try StackHawk today - Start your free trial
Watch a demo
Discover more on our Hawkdocs page

The Ultimate Guide to API Security Testing: Best Practices and Essential Tools

StackHawk

As Application Programming Interfaces (APIs) have grown in use and abundance, so has the number of attacks and breaches stemming from said APIs. The OWASP API Security Project and OWASP API Security Top 10 have helped to highlight the types of vulnerabilities that developers should be conscious of and defend against.

APIs are not only the backbone of modern application architecture, but they are also vital for maintaining security. Typically, a company’s most valuable and sensitive data resides behind an API. Delivering secure applications relies on ensuring that the underlying APIs are free from security vulnerabilities.

Delivering secure APIs, however, is easier said than done. APIs sit at the intersection of engineering and security teams, and typically see rapid iteration as software is built and improved. Ensuring API security raises questions such as:

Which team is responsible for maintaining API security?
How do we ensure that updates to our APIs do not create a vulnerability?
Does our team have API security testing?

Modern software development teams are solving this problem with developer-centric API security testing automated in CI/CD. The rest of this post has more information on what API security testing is, how it works, and what to look for in selecting a top security testing vendor. Read on to learn more.

What is API Security Testing?

API security testing is the process of identifying vulnerabilities in APIs to ensure that they are secure against potential threats. APIs serve as the backbone of modern applications, connecting different systems and allowing data exchange, which make them a prime target for attackers. By performing security tests, teams can discover vulnerabilities such as improper authentication, data exposure, or other business logic vulnerabilities, flaws that could be exploited by malicious actors. Ensuring the security of APIs is vital to protect both the underlying infrastructure and sensitive data.

The Adoption of DevOps Practices

Historically, API security testing was conducted by enterprise security teams through manual scans and penetration testing. These methods were often time-consuming and occurred late in the development cycle, leading to the delayed discovery of issues.

However, with the adoption of DevOps practices, API security testing is increasingly integrated into the software development lifecycle (SDLC). This shift to continuous testing as part of the DevOps pipeline allows developers to catch security issues early, reduce vulnerabilities, and respond more quickly to potential threats, thereby improving the overall security posture of their applications.

Understanding API Security Risks

APIs are critical to modern applications, but they are also vulnerable to various security risks. Understanding these risks is key to developing an effective API security strategy and safeguarding data, systems, and operations. Below, we explore some of the most common API security threats.

Injection Attacks

Injection attacks, such as SQL or command injections, occur when untrusted data is sent to an interpreter, resulting in unintended commands being executed. APIs are particularly vulnerable to this type of attack when they do not properly validate and sanitize inputs. An attacker can use this weakness to manipulate queries or execute commands, leading to data theft, corruption, or control over the system. To reduce the risk of injection attacks, it is essential to implement input validation and use parameterized queries.

Broken Authentication and Session Management

APIs often handle authentication and session management, which are common targets for attackers. Weaknesses in these areas can result in unauthorized access to sensitive information or the hijacking of user sessions. Broken authentication occurs when API keys, tokens, or credentials are improperly managed or exposed, allowing attackers to impersonate users. Implementing strong authentication methods, such as OAuth or multi-factor authentication (MFA), can help minimize this risk.

Insecure Direct Object References (IDOR)

Insecure direct object references occur when an API exposes internal objects, such as files or database records, to unauthorized users. This vulnerability enables attackers to tamper with input, allowing them to access data they shouldn't be able to. For instance, an attacker could alter an API endpoint to gain unauthorized access to another user's information. To mitigate the risk of IDOR, it is vital to enforce strict access controls and thorough authorization checks.

Denial-of-Service (DoS) Attacks

Denial-of-service (DoS) attacks are designed to overwhelm an API with excessive requests, rendering it unavailable to legitimate users. Attackers can exploit weaknesses in the API’s rate limiting or request handling mechanisms, leading to service outages. Implementing rate limiting, throttling, and monitoring can help mitigate the risk of DoS attacks and ensure that APIs remain operational under stress.

Consequences of API Security Risks

The consequences of failing to address API security risks can be severe, including data breaches, reputational damage, and financial losses. A successful attack can lead to the exposure of sensitive customer or business data, resulting in a loss of trust and potential legal penalties. In more extreme cases, compromised APIs can give attackers control over critical systems, amplifying the scope of damage.

By understanding these risks and adopting proactive security measures, organizations can significantly reduce their exposure to API-related threats and maintain the security of their applications and data.

Preparing for API Security Testing

Effective API security testing begins with thorough preparation, which includes setting up a reliable testing environment, identifying the scope of testing, and ensuring the right tools and resources are in place.

Setting Up a Testing Environment

Creating a testing environment that mirrors the production environment as closely as possible is critical for obtaining accurate results. This means replicating the same API configurations, authentication mechanisms, and traffic conditions that exist in the live environment. By doing so, you can identify vulnerabilities that may only surface under real-world conditions. The testing environment should also be isolated to prevent any unintended impacts on production data or systems.

Defining the Scope of Testing

Before starting, it's essential to define the scope of the security testing to ensure that all critical aspects of the API are examined. This involves identifying which endpoints, authentication mechanisms, data flows, and external integrations need testing. Scoping should also consider the types of threats you're most concerned about, such as injection attacks, data exposure, or unauthorized access, to tailor the testing approach accordingly. A well-defined scope helps focus security testing efforts and ensures comprehensive coverage of potential vulnerabilities.

Gathering Tools and Resources

Once the environment and scope are established, the next step is to gather the necessary tools and resources. This includes selecting automated API security testing platforms like StackHawk, as well as manual testing tools like Burp Suite for more in-depth analysis. In addition to tools, it's important to ensure that your team has access to relevant documentation, such as API schemas and security policies, to effectively guide the testing process. With the right combination of tools and expertise, the security testing process can be efficient and thorough.

Proper preparation is a key factor in the success of API security testing, enabling teams to identify vulnerabilities, mitigate risks, and improve the overall security of their APIs.

Types of API Security Testing

The types of API security testing that could be performed are vast. Some are more manual, like API penetration testing, while others are more automated. When uncovering a potential API vulnerability, specific methods may be more applicable than others. For instance, if certain API security issues arise only during runtime, then it's necessary to use an API security testing tool that can evaluate the application while it's running. Meanwhile, other vulnerabilities might be detected through static analysis by using a static vulnerability scanner on the code base. With this in mind, let's take a look at a few types of API security testing tools.

Dynamic API Security Tests

While some static analysis security testing (SAST) and software composition analysis (SCA) tools have coverage for APIs, the best form of API security testing is running active (dynamic) tests against your API endpoints. This active testing is technically a form of dynamic application security testing (DAST). However, be cautious of legacy DAST tools that are not designed for API testing.

Running a dynamic API security test simulates a real API-based attack, revealing vulnerabilities stemming from both open-source dependencies and your team's code. Ideally, for the most robust API security testing, you should combine dynamic testing with SAST and SCA. However, if you're seeking an effective initial step to begin securing your APIs, dynamic testing is the recommended approach.

Static API Security Tests

Static Application Security Testing tools analyze an application's source code to pinpoint potential vulnerabilities. These tools scrutinize the code for patterns that may indicate security risks. Being language-specific, SAST tools require a match with the programming language used to write your API. To ensure effective analysis, you must select a static analysis tool that is compatible with the language of your API.

Software Composition Analysis

Software Composition Analysis tools look at the dependency tree of your application and match this against a database of known vulnerabilities. By using these tools, you would be alerted to any known vulnerabilities in libraries or frameworks that your application or API utilizes. With the ever-increasing use of open source in API development, these tools are essential to include in security testing. The limitations of SCA tools are that (1) they typically do not indicate whether a detected vulnerability is actually exploitable within your API, and (2) they focus solely on identifying vulnerabilities in open-source components, overlooking security flaws that your team might have introduced.

API Security Testing Best Practices

API security testing best practices focus on following established standards, staying updated on emerging threats, and maintaining continuous vigilance through monitoring and retesting.

Adhering to Industry Standards

To secure APIs effectively, organizations should follow established guidelines like the OWASP API Security Top 10. These standards offer a comprehensive list of common vulnerabilities, such as broken object-level authorization and improper authentication. By aligning with these guidelines, teams can implement proactive security measures and mitigate potential threats early.

Staying Updated on Evolving Threats

The API threat landscape is constantly evolving, requiring development and security teams to stay informed about new vulnerabilities and security practices. Regular updates and patches are essential to prevent attackers from exploiting known issues and to maintain robust security.

Continuous Monitoring and Retesting

API security doesn’t end with deployment. Continuous monitoring for vulnerabilities, combined with periodic retesting, ensures that newly introduced weaknesses are swiftly addressed. This ongoing vigilance is crucial in dynamic environments where APIs are frequently updated and integrated with other systems, helping organizations maintain a strong security posture over time.

Implementing Strong Authentication and Authorization

Ensuring that only authenticated and authorized users can access API resources is critical. Best practices include using OAuth or similar industry-standard protocols for managing authentication, along with role-based access control (RBAC) to enforce authorization rules.

Securing Data in Transit and at Rest

To guard against data interception or tampering, it is crucial to ensure API communication is secure by encrypting data both during transmission and while stored. Use Transport Layer Security (TLS) for encrypting API traffic, and apply encryption to sensitive data in databases, thus preventing unauthorized access.

By following these best practices, organizations can significantly reduce the risk of API vulnerabilities and ensure secure API management throughout the development lifecycle.

Essential API Security Testing Tools

API security testing relies on a mix of automated and manual tools to ensure comprehensive coverage. Automated tools, such as API security testing platforms, streamline the process by integrating into DevOps pipelines, allowing for consistent testing and faster feedback. These platforms often include capabilities for detecting common vulnerabilities and automating fixes. Notable platforms discussed in recent reviews include tools like StackHawk, Postman, and Swagger.

Manual Testing Tools

On the manual side, tools like Burp Suite offer deeper, hands-on analysis. These tools allow both security professionals and engineers to perform penetration tests, actively probing APIs for vulnerabilities that automated tools might overlook. For instance, Burp Suite is praised for its extensive features for manual testing and its ability to integrate with automated processes.

For more details, the Top 10 API Testing Tools emphasizes how integrating both automated and manual tools ensures robust API security. Additionally, Dynamic Application Security Tools and API Discovery Tools are essential for covering gaps, providing a complete toolkit for effective API testing and security management.

API Security Testing Automation with StackHawk

API security testing automation involves using tools like StackHawk to perform security testing and streamline the identification of vulnerabilities. StackHawk is designed for seamless integration into the CI/CD pipeline, making it easy to catch API security issues early in the development process. By automating the testing process, StackHawk continuously scans APIs for potential vulnerabilities, such as authentication flaws or data exposure, and provides actionable insights for developers to fix issues quickly.

Although StackHawk simplifies the security process, it is essential to complement automated testing with manual checks for complex vulnerabilities. Automated testing reduces human error, ensuring consistent, repeatable tests with every API update, which ultimately enhances the overall security posture. By using StackHawk’s automation, teams can efficiently incorporate security into their DevOps workflow and maintain a higher level of security throughout the API lifecycle.

Specialized API Security Testing Scenarios

Specialized API security testing focuses on ensuring that critical mechanisms within the API are secure, including authentication, authorization, input validation, and error handling.

Authentication and Authorization: Testing these mechanisms is essential to ensure that only legitimate users can access the API and that users have the correct permissions. Misconfigured authentication can expose sensitive data or functionality to unauthorized users.
Input Validation: Proper input validation prevents injection attacks such as SQL injection and ensures that data integrity is maintained. APIs must validate all input to prevent attackers from sending malicious data.
Error Handling: It’s crucial to test error handling to prevent information disclosure vulnerabilities. Poorly handled errors can reveal sensitive system information, which attackers can exploit to discover weaknesses in the API.

By focusing on these specialized testing scenarios, API security can be significantly strengthened, protecting critical application components from various attack vectors.

Conclusion

API security testing is crucial for protecting sensitive data and ensuring the integrity of your applications. By performing security testing, following best practices, utilizing essential tools, and incorporating automation, organizations can strengthen the security of their APIs. However, security testing is an ongoing process, requiring continuous monitoring and retesting to stay ahead of emerging threats.

To make API security testing more efficient and proactive, consider using StackHawk. StackHawk offers automated API security testing that integrates directly into your CI/CD pipeline, helping you catch vulnerabilities early. Learn more about StackHawk and start securing your APIs today.

The Best API Monitoring Tools to Enhance Your Application Performance and Security

Matt Tanner

Just like any core piece of your application and architecture, APIs require a specific set of tools to ensure they are running smoothly. The main part of this tool set is API monitoring tools, which can help ensure that APIs are performant and detect potential issues, including runtime security issues.

In this blog, we will look at 15 of the most popular API monitoring tools. However, before we dive into some of the specific tools you might deploy for API monitoring, we should answer the obvious question - what even IS API monitoring in the first place?

What is API Monitoring?

API monitoring is the process of gathering data, visualizing it, and building alerts and functionality based on the telemetry data reported from an API (or Application Programming Interface). This process ensures that API requests are handled as expected, allowing for the generation of infrastructure metrics, real user monitoring, integration tests, and much more.

There's a few obvious benefits of API monitoring - notably an increase in the visibility of the entire platform. But beyond the immediate benefits, there are some not-so obvious tack-on benefits that really make this process worthwhile.

First and foremost, API monitoring plays an important role in helping teams surface API-related issues, such as errors, issues with latency, and security vulnerabilities, before they become a more significant problem and negatively impact services, partners, and customers.

Secondly, this process can point to symptomatic issues that may not directly affect your API but certainly impact your customers. An effective testing regime can surface issues with external APIs, integration system performance, security considerations with partner APIs, and even secondary platforms such as mobile app testing.

Key API Metrics to Monitor

It's important to remember that the ultimate goal of API monitoring is to generate long-term or instant actionable insights - as such, the key metrics you track are going to play a huge role in the efficacy of the system, not to mention the API errors that you can actually track.

For the purposes of this guide, we've broken these metrics into some general categories. That being said, specific measurements beyond these fundamental metrics may be appropriate depending on your specific use case.

Uptime and Availability

Uptime is a relatively fundamental metric in API monitoring, representing the average amount of time that a service has been live. This, combined with availability, or the average amount of time that a live service has been usable, represents strong metrics that point towards the health of a service.

Let's look at an example. A 99.999%, or "five nines" uptime, suggests that a service has been live for 99.999% of the time. A service that has been live 99% of the time, or "two nine's", has only been live 99% of the time.

That might seem like a small difference, but if you do the math, it certainly adds up - a "five nine's" service means that across the 8,760 hours in a year, a service was available for 8759.9 hours. For a "two nine's" service, it was only available for 8672.4 hours, meaning it was down for 87.6 hours, or almost 3 and a half days.

Availability and uptime monitoring can be done across a whole service or specifically focused on a given API endpoint for granularity. High API uptime and availability of the whole service point towards a healthy codebase and operational environment.

Response Time and Latency

Response time is the time it takes for an API to process a request and return the response to the requesting client. This value is a relatively good estimate of the state of the network between the server and the client, but it can be affected by many internal factors. Latency is a good metric to pair with this, as it reflects the delay between the request and the response and is very much focused on the internal state of the service.

In context, these two give a great view of the health of the service as well as the general health of the environment in which it operates, the network timing data, and even potential client faults or delay with multiple requests. Specific browser tests can then be deployed to find if these issues are universal or specific to a given build or interface, increasing awareness and giving options for improvement.

Minimizing latency and response time ultimately results in better performance for the end user, and when you use the proper methodologies - such as caching, geolocating resources closer to clients in cloud-based systems, optimizing API transactions, etc. - this ultimately results in significantly optimizing application performance.

Resource Usage

Another huge data source has to do with your resource usage. This usage includes the use of things like network bandwidth as well as local resources such as memory and CPU utilization. These metrics will help you understand how efficient your system is, and in the context of the size of the system and the number of third-party APIs or integrations, can also help you understand whether the issue arises from your API calls, your API functionality, or something further down the pipeline like the network standards or transit environment.

A lot of this data can be sourced at the same time that you're doing your infrastructure monitoring, as they're often part and parcel with one another. High CPU usage can have a huge impact on latency, for example, as it suggests that your system is either not adequately resources or that it is inefficiently designed.

These performance monitors can give you an idea of proper scalability as well, pointing both towards general inefficiencies as well as potential for improvement to server resourcing.

15 API Monitoring Tools

With all of this understood, let's look at 15 common tools for monitoring APIs.

1 - Postman API Monitoring

Provider: Postman
Summary: As part of their popular API toolset, Postman offers a relatively comprehensive system for testing and monitoring at scale. It's a relatively strong solution, offering real-time alerting and a decently easy setup process, but it's most ideal for those already utilizing Postman for API development.
Pros
- Easy to integrate with Postman workflows
- Strong real-time alerting solution
- Decently simple setup means you can get started quickly
Cons
- Offers little in the way of advanced monitoring
- Better suited for people already utilizing Postman - it's less strong a solution for those not in that ecosystem

2 - New Relic One

Provider: New Relic
Summary: New Relic One is a relatively comprehensive platform for monitoring and observability, offering real-time performance monitoring for real-time insights. It’s highly customizable and integrates well with multiple services, though it may require a learning curve for optimal use.
Pros
- New Relic One is a comprehensive monitoring suite
- Offers high-value, real-time data
- Offers a ton of options for integration with different services
Cons
- Can be expensive, especially depending on the complexity of your backend
- Can be very complex to set up initially

3 - Datadog API Monitoring

Provider: Datadog
Summary: Datadog’s API monitoring provides a full view of distributed systems, allowing you to set custom alerts and track performance across a varied environment. Its dashboard is flexible and detailed, though usage-based pricing may make it costly for high-demand environments.
Pros
- Excellent for distributed systems
- Highly customizable alerts make it easy to track specific metrics
- A flexible dashboard allows anyone to generate insights with relative ease
Cons
- Pricing is based on usage, which can be costly
- While it's easy to get started, it has a steep learning curve to really get the most out of the service

4 - Uptrends

Provider: Uptrends
Summary: Uptrends offers uptime monitoring and performance tracking with a well-featured tool set. It includes features like browser emulation, allowing you to test a wide variety of environments and client use cases. It’s a good choice for some specific criteria, though customization options for API requests are somewhat limited.
Pros
- User-friendly interface that is easy to get started with
- Reliable uptime and performance checks
- Browser simulation unlocks a ton of variable testing and monitoring options
Cons
- Limited API request customizations
- Can be costly if you end up using the complete feature set

5 - APImetrics

Provider: APImetrics
Summary: APImetrics is a specialized API monitoring tool offering SLA compliance tracking and multi-region testing. It provides deep analytics, and is especially useful for monitoring SLAs.
Pros
- Comprehensive analytics system with multi-region testing
- Very effective SLA compliance tracking
Cons
- UI is somewhat unintuitive
- APImetrics doesn't offer as complete a set of integration options

6 - Runscope

Provider: CA Technologies
Summary: Runscope excels at debugging and tracking HTTP requests, making it ideal for tracking API performance across the network. However, advanced monitoring features are limited, and it can be costly for larger teams.
Pros
- Great for debugging and efficiency hunting
- Allows HTTP request/response tracking
- Designed with team collaboration in mind
Cons
- Limited advanced features beyond the collaborative tooling
- This collaborative tooling comes at a high cost, which can be prohibitive for large teams

7 - Prometheus

Provider: Cloud Native Computing Foundation
Summary: Prometheus is an open-source, customizable tool designed specifically for time-series data. It’s relatively popular among developers who need high flexibility, though it requires significant setup expertise and isn’t as user-friendly as other options on the market.
Pros
- An open-source tool, which makes it highly customizable and cheap to utilize
- Great specifically for time-series-centric data
Cons
- Relatively difficult to get set up, as there's no product bundling common with enterprise software offerings
- Not as user-friendly as the plug-n-play solutions on this list

8 - API Fortress

Provider: API Fortress
Summary: This tool offers a no-code setup and strong integration options, making it accessible for teams without extensive coding knowledge. API Fortress is very particular in terms of its design and workflow, however, and the UI can be challenging for new users.
Pros
- API Fortress offers a ton of options for integration
- The load testing tooling is pretty feature-rich
- No-code automation brings the benefits of automation to teams that might not otherwise have that skillset
Cons
- The UI can, at times, be overwhelming, making it hard to track essential metrics without prior experience

9 - Kong Enterprise

Provider: Kong Inc.
Summary: Kong provides API gateway and management services with additional built-in tooling for API monitoring. It’s well-suited for enterprise environments, but it might be too complex for smaller teams, less complex services, and beginners just starting their development journey.
Pros
- Since Kong is a feature set rather than a single tool, it has a ton of key features that make gathering performance data, managing multiple locations, and monitoring API calls relatively easy
- It's highly customizable for a variety of environments and use cases
Cons
- Although you may not be ready to buy wholesale into the Kong ecosystem, the management services are bundled together, introducing excess cost and management
- You can do a lot with Kong, but to really get optimal performance out of it, you need significant prior technical knowledge

10 - AWS CloudWatch

Provider: Amazon Web Services
Summary: AWS CloudWatch is specifically designed for AWS users to generate detailed performance metrics across their deployment, offering customizable alerts and deep context. It's not beginner-friendly, however, and the focus on AWS - as well as the associated cost - can be a deal breaker.
Pros
- This is by far the most seamless solution for AWS ecosystem APIs, providing granular data and customizable alerts across external and internal APIs
- Its log management solution is second to few, providing ample information alongside dedicated visualization tools
Cons
- CloudWatch is powerful, but this power comes with cost - both in terms of money and in terms of the expert knowledge required for its use
- This is a solution that is plugged directly into the AWS world - Google Cloud APIs and other third-party solutions will find this less than useful

11 - Ghost Inspector

Provider: Ghost Inspector
Summary: Ghost Inspector is specifically designed for functional API testing and monitoring, focusing on browser-based visual regression tests. It’s easy to use but lacks in-depth API monitoring metrics outside of this niche use case.
Pros
- Great for functional API tests, browser-based tests, and regression tests, all of which are typically underserved by "one-stop shop" solutions
Cons
- Limited advanced API monitoring metrics limit its API usage to basic awareness of API endpoints and specific types of tests
- It does really well at a few things, but it's not really a comprehensive API monitoring solution

12 - Catchpoint

Provider: Catchpoint
Summary: Catchpoint is a tool that provides reliable global monitoring as well as detailed troubleshooting data. It’s a powerful tool, but it can rapidly become to expensive for small teams. It is also relatively complex to get up and running, which can be a blocker for all but the most experienced teams.
Pros
- Catchpoint provides reliable data validation in addition to its monitoring suite
- Reliable, detailed data for troubleshooting
Cons
- Catchpoint is powerful, but it's not a very intuitive tool, which can result in a significant learning curve
- It can also be quite expensive for small teams, especially due to how complex it is to initially set up

13 - Honeycomb

Provider: Honeycomb.io
Summary: Honeycomb excels at distributed tracing and is highly scalable, making it popular among larger teams. However, its pricing can be a barrier, and the complexity on offer isn't really idea for basic monitoring use cases.
Pros
- Great for complex tests requiring distributed tracing or differential global endpoints
Cons
- Honeycomb is another tool that is very good but very expensive - this cost might be more than a team is willing to spend (or more than a team is able to spend) for something simple, such as the need to monitor API performance or memory usage

14 - Checkly

Provider: Checkly
Summary: Checkly is an easy-to-set-up browser-based API and web monitoring solution. While intuitive, it often lacks deep analytics pathways and has limited integrations compared to more advanced tools.
Pros
- Checkly is incredibly easy to get started with and remains easy to use in a variety of environments
- It provides both API and general web traffic monitoring
Cons
- Checkly lacks deeper analytics systems, making it hard to suggest for API failures rooted in more complex end states, systems that need more comprehensive synthetic monitoring, and so forth
- Add on to this the reality that Checkly has limited integrations, and you're going to run up against limitations rather quickly

15 - UptimeRobot

Provider: UptimeRobot
Summary: UptimeRobot is a case of a product that is really simple, providing just what it says on the tin - and very little else. While it supports some good basic monitoring, it lacks detailed analytics and other advanced features.
Pros
- It's highly affordable, easy to set up, and supports a wide variety of protocols
Cons
- All of its pros said, it has limited API testing metrics and lacks deep, detailed analytics

Choosing the Right API Monitoring Tool

Considerations for Selecting an API Monitoring Tool

How you go about choosing the right tool to monitor APIs is going to depend largely on your given environment. Assuming you have the correct data, well-structured APIs, and systems following best practices, as well as a system that does not have a specific use case or test that it needs (which narrows your choices), you're going to want to look for the following:

Intuitive interface: a user-friendly interface that simplifies navigation and operations will be incredibly important, especially for a tool that is used by multiple teams for collaborative API monitoring. Ease of use will make your tool more likely to see use, which will make it that much more effective.
Reusability: the capability to recycle tests will make for efficient and consistent monitoring. Make sure you are able to control your code granularly instead of relying on pre-built packaged testing for improved results.
Run options: the flexibility to execute tests on-demand, to schedule testing intervals, or to launch tests in response to specific events will be very important. Make sure your chosen solution offers as many options as possible for controlling your testing regime.
Sequencing: ensure your solution allows you to control the sequencing of tests. It's not good enough to just run one mega test - you need to be able to control each test as well as the order that they are executed in order to get a full view of your data flow.
Alerts: ensure you have adequate control over notifications and alerts, setting up systems that are triggered by predefined thresholds which can indicate API performance issues or deviations. Additionally, ensure those alerts are actually useful - alerts should come with an error code, not random abstract warnings of failure!

Monitoring is Not Enough For Security!

As you read the above list of the best API monitoring tools, you might come to a simple but unavoidable conclusion - API monitoring is great but entirely reactive. Even the most comprehensive API monitoring strategy is only half the story. Monitoring is, by definition, the process of observing a failure state, and in many situations, you cannot let the failure state happen even once.

Securing your APIs before they have a huge security issue should be your number one priority, and then validating the effectiveness of that strategy should be the realm of your API monitoring regime. In that vein, how can one adequately resolve potential issues at scale?

StackHawk is an incredibly powerful testing solution that resolves this issue before you hit production. In other words, StackHawk's DAST solution shifts security left, integrating and automating within the CI/CD pipeline itself. By integrating with the DevOps pipeline, this DAST system can surface vulnerabilities before they put your production services—and your users' data—at risk.

In essence, DAST—or Dynamic Application Security Testing—is a simple and effective way to build more secure software faster and apply security principles more efficiently. StackHawk focuses on runtime and pre-production security testing, allowing you to integrate security into the development process rather than "tacking it on" as an afterthought.

Beyond the apparent technical security benefits StackHawk's DAST solution offers, StackHawk goes even further by introducing API discovery and the latest feature, API Oversight, rounding out the three core pillars of API Security. With the three core pillars, StackHawk users can ensure that every API is documented and tested and that their entire attack surface is covered—the perfect complement to a holistic API monitoring stack.

Conclusion

Monitoring is simply not enough - in order to ensure your API is performant, reliable, and secure, you need to adopt a monitoring solution that validates your security approach. With these two processes working in tandem, you can ensure a highly secure and effective production pipeline and monitoring strategy that will result in happy customers, secure databases, and solid code.

Getting started with StackHawk is incredibly easy! If you'd like to shift your security left and start building more robust and dependable code bases, you can start a free trial today!

Your AppSec Journey Demystified: Driving Effective API Security with StackHawk and Wallarm

Scott Gerlach

There is no doubt that attackers have shifted their attention to APIs. Wallarm’s API ThreatStats research identifies that 70% of attacks now target APIs instead of Web Applications. While APIs have become the backbone of innovation and connectivity for businesses, they have also introduced a vast attack surface that’s challenging to defend with traditional methods alone. To address these unique API security needs, StackHawk and Wallarm have partnered to provide a powerful, combined solution that makes proactive API security seamless, scalable, and highly effective.

The Complex API Security Landscape

APIs enable businesses to scale, adapt, and integrate like never before, but they also bring unique security challenges that traditional tools struggle to handle. With APIs proliferating rapidly, companies need a comprehensive approach to API security—one that provides visibility, protects against evolving threats, and aligns with rapid development cycles. Wallarm and StackHawk’s combined solution offers exactly that.

Key API Security Challenges:

Unknown Risks: APIs may be unknowingly exposed or exposed to unknown threats if not continuously discovered, monitored, and secured.
Complex Threat Landscape: As APIs, their infrastructure, and interactions grow more complex, so do the potential vulnerabilities and attacks.
Operational Constraints: Security solutions must seamlessly integrate with modern development workflows and deployed infrastructure, without negatively impacting performance.

StackHawk and Wallarm: A Stronger, Shift-Left Approach to API Security

Together, StackHawk and Wallarm deliver a robust, “shift-left, shield right” security strategy designed to empower application security teams with proactive API discovery, continuous testing, and real-time threat detection. By joining forces, they address the entire API lifecycle, helping teams discover, monitor, and secure APIs from development to production.

Better Together: The StackHawk + Wallarm Solution:

Multi-Faceted, Proactive API Discovery: With StackHawk, developers gain visibility into their API landscape through discovery integrated within their CI/CD. Wallarm provides dynamic API discovery through external scanning and active traffic analysis.
Integrated, Continuous API Security Testing: StackHawk integration with both Wallarm and the CI/CD pipeline supports continually updated and continuous API security testing.
Shield-Right with Real-Time Threat Protection: Wallarm detects and actively blocks API attacks by monitoring live API traffic. .
Built for Scale and Speed: This combined solution is designed to support teams of all sizes, integrating seamlessly into CI/CD pipelines and API infrastructure without slowing down development.

The Benefits of a Unified, Proactive API Security Strategy

By integrating StackHawk and Wallarm, companies can transition from a reactive approach to a strategic, proactive one that meets the security demands of today’s API-driven world. Together, these tools empower organizations to safeguard their API ecosystem, ensuring compliance, protecting sensitive data, and enabling secure innovation.

Advantages of the StackHawk and Wallarm Partnership:

Enhanced Security Posture: Catch vulnerabilities early with StackHawk’s shift-left testing, then continuously monitor and mitigate threats in real-time with Wallarm.
Increased Productivity: Secure APIs without disrupting development workflows, thanks to fast and seamless integration.
Streamlined Compliance: Simplify audits and meet regulatory requirements through continuous API security and monitoring.

Easy Onboarding, Immediate Impact

Getting started with StackHawk and Wallarm is straightforward. With StackHawk’s user-friendly API discovery and Wallarm’s threat protection, your team can achieve end-to-end API security that aligns with development speed. StackHawk provides tabular insights, filtering, and commit tracking to streamline oversight, while Wallarm’s robust detection and real-time blocking make continuous monitoring actionable.

Conclusion

APIs are central to business growth, and securing them requires a modern approach. Together, StackHawk and Wallarm provide a best-of-breed solution for API security that combines proactive oversight with real-time protection. For companies ready to take their AppSec program to the next level, StackHawk and Wallarm offer the tools needed to stay secure and scale confidently. Start your journey with StackHawk and Wallarm—where proactive and continuous API security come together to enable secure innovation.

To learn more about how Wallarm and StackHawk integrate, download the datasheet.

Creating Test Cases for API Testing: A Comprehensive Guide with Examples

Matt Tanner

APIs are critical in modern software, allowing different systems to communicate and share data. When APIs fail, it can lead to anything from minor bugs to significant disruptions that impact users and businesses.

In API testing, you systematically review the API’s performance to ensure it works as expected. Catching and fixing problems early in development improves the software’s quality and speeds up development cycles.

What is API Testing?

API testing is software testing focused on ensuring APIs meet specific standards for functionality, reliability, performance, and security. Rather than relying on traditional user inputs (like a keyboard or mouse) or visual feedback (like a screen display), you interact with the API through software tools, sending requests and reviewing the system's responses.

Typically, API testing takes place at the message layer without involving a graphical interface (GUI). Instead of navigating a website or app, you work directly with the API by sending requests and evaluating responses. This approach allows us to test specific API functions independently, making the testing process faster and more accurate.

Why API Testing Matters

API testing offers a range of benefits that contribute significantly to creating robust and reliable applications. One of its primary advantages is detecting bugs early in the development lifecycle. By identifying and addressing issues at this stage, developers can prevent them from escalating into more complex problems, saving valuable time and resources in the long run.

API testing allows for improved test coverage compared to traditional UI testing. It can probe deeper into the application's core functionality, including business logic and data responses, ensuring that all critical components are thoroughly examined. This approach leads to higher software quality and reduces the risk of unexpected behavior.

The speed at which API tests can be executed is another benefit. These tests are typically faster than UI tests, enabling rapid feedback loops and accelerating development cycles. This efficiency allows for more frequent software updates and the timely release of new features, keeping pace with evolving user needs and market demands.

API testing also plays a vital role in enhancing application security. Identifying vulnerabilities like authentication flaws that may lead to potential data breaches helps developers build more secure systems. This proactive approach to security minimizes the risk of exploitation and protects sensitive data.

Finally, API tests are highly suited to automation, making them ideal for integration into continuous integration and continuous delivery (CI/CD) pipelines. This automation streamlines the development process, ensures consistent software quality, and facilitates a more efficient workflow. In conclusion, API testing is indispensable for any development team striving to deliver high-quality, secure, and reliable software.

Understanding API Documentation for Testing

API documentation outlines everything you need to know about the API's functionalities, endpoints, request methods, parameters, and expected responses. Here's why understanding documentation is key when it comes to effective API testing:

Identify Test Scope and Create Test Cases

Good documentation gives you a clear picture of what the API can do. This helps you set up the boundaries for your tests and create test cases that cover every important function. For each endpoint, the documentation tells you which request parameters, headers, and response codes to expect so you know exactly what you’re testing and why.

Understand Expected Behavior and Troubleshoot Errors

The documentation outlines how the API should behave under different conditions so you’ll know if it’s working as expected. This is your go-to resource if you hit unexpected results or error codes. Often, you’ll find detailed descriptions of error codes and what they mean, which can speed up your troubleshooting and help you resolve issues faster.

Types of API Testing

API testing covers a range of test types, each aimed at examining a different aspect of the API’s functionality and performance. Here are some of the most common types of API testing and why they matter:

Functional Testing

This is all about ensuring that each part of the API works as expected. Functional testing checks specific endpoints, request methods, and parameters, making sure they produce the correct responses based on their design. It’s like testing each piece of the puzzle to see if it fits as it should.

Performance and Load Testing

Performance testing evaluates how the API handles various demands—think of it as stress-testing the API. It identifies potential bottlenecks by looking at factors like response time, stability, and scalability. Load testing is a specific form of performance testing that simulates high user demand to see how well the API performs under pressure.

Security Testing

Security testing focuses on identifying vulnerabilities that could leave the API open to attacks. It tests authentication, authorization, and data encryption to ensure that sensitive API data is protected and only authorized users can access specific functions.

Contract Testing

This type of testing verifies that the API sticks to its "contract" with the consumers—meaning, it meets the expectations around response data formats and structure. If an API’s contract changes unexpectedly, it could break integrations, so contract testing helps ensure everything remains in sync.

Integration Testing

Integration testing checks how well the API interacts with other parts of the application or external systems. It’s designed to catch any issues with data flow between components and ensure that the API plays well with other pieces in the larger system.

By using these different types of testing, you get a well-rounded view of the API’s performance, functionality, and security, helping to ensure that it works reliably and meets all necessary requirements.

Writing Effective Test Cases for API

Writing clear, effective test cases is key to successful API testing. Each test case should focus on a specific aspect of the API, laying out the inputs you’ll use, the expected results, and the steps you’ll follow. Here’s a breakdown of what makes a solid API test case:

1. Define the Test Objective

Start by clearly stating the purpose of the test. What specific part of the API are you checking? For example, “Verify that a new user can be created successfully.”

2. Identify the API Endpoint

Specify the exact endpoint you’re testing, including the URL and any path parameters. This keeps things focused and ensures you’re testing the right part of the API.

3. Specify Request Details

Outline the HTTP method (GET, POST, PUT, DELETE, etc.) and any necessary headers, like authorization tokens or content types. If the request requires data (like a POST or PUT), detail what needs to go in the body, often in JSON or XML format.

4. Outline Test Steps

Lay out each step in a sequence—send the request, receive the API response, and note specific parts of the response that need validation. Having a clear sequence makes the testing process straightforward, especially for manual testing.

5. Define Expected Outcome

Clearly state what should happen. This might include an HTTP status code (e.g., 200 OK for a successful request) and the structure or content of the response data. Detail expected values, data types, and how the response body should look.

6. Include Assertions

Assertions are key for automating tests, as they compare the actual outcome with the expected one. Including assertions lets you know instantly if the test passed or failed, making the results easy to interpret.

Example Test Case

Objective: Verify successful user creation.

Endpoint: /users

Method: POST

Headers: Content-Type: application/json

Body:

Steps:

Send the POST request to the /users endpoint with the provided headers and body.
Receive the API response.

Expected Outcome:

Status Code: 201 Created
Response Body: JSON object containing the newly created user's details.

Assertions:

Assert that the status code is 201.
Assert that the response body contains the user's username, email, and a unique user ID.

By following these guidelines, you can write effective test cases that are clear, concise, and focused, ensuring comprehensive API testing and contributing to the overall quality of your software.

API Testing Checklist

API testing involves many moving parts, so having a checklist can keep you on track and ensure you don’t miss anything. Here’s a practical checklist to guide you through each stage of the testing process:

Before Testing

Understand the API's Purpose: Review the documentation to get a solid grasp of the API’s functions, endpoints, and expected behavior. Knowing what the API is supposed to do will make your testing more targeted and effective.
Define the Testing Scope: Determine which parts of the API need testing based on factors like risk, importance, and business requirements.
Set Up the Test Environment: Ensure you have a dedicated testing environment with the necessary tools and test data ready to go.

During Testing

Measure Response Times: Check how responsive the API is under different conditions, including normal and peak loads. This is crucial for ensuring it performs within acceptable limits.
Validate Response Body and Status Code: Confirm that the API is returning the right status code (e.g., 200 OK, 404 Not Found) and that the response body contains the expected data in the correct format (usually JSON or XML).
Validate Response Headers: In addition to the response body and status code, pay attention to the response headers. Ensure they are set correctly and contain the expected values, like content type or cache control settings.
Verify Data Format and Validation: Confirm that the API accepts and returns data in the correct format (JSON, XML) and performs appropriate data validation. This is especially important for inputs like date formats, required fields, and data types.
Explore Edge Cases and Boundary Conditions: Don’t just stick to the usual “happy path.” Try unexpected inputs, invalid data, and edge cases to see if the API handles errors gracefully and provides useful error messages.

After Testing

Document Test Results: Record all your test results, including successes, failures, and any other observations. This helps with future reference and tracking.
Report and Track Bugs: If you find any issues, report them and track their resolution. Having a system to log bugs makes it easier to follow up and ensure they’re resolved.
Continuously Monitor the API: Implement monitoring tools to track the API's performance and health in production.

By following this checklist, you can systematically approach API testing, ensuring comprehensive coverage and increasing the likelihood of identifying and resolving potential issues before they impact your users.

Tools and Frameworks for API Testing

The right tools can significantly streamline your API testing process, enabling you to automate tests, analyze results, and improve efficiency. Fortunately, many popular tools and frameworks are available to help you achieve these goals. Here's a list of some of the most popular tools available:

StackHawk

StackHawk is a dynamic application security testing (DAST) tool focused on catching and fixing API security issues. StackHawk integrates easily with CI/CD pipelines, helping you to automate security tests for common risks like those in the OWASP Top 10. It also provides clear, developer-friendly reports and advice on remediating any issues.

Postman

Postman is one of the most popular tools for API testing and development, offering a user-friendly interface for sending requests, viewing API responses, and creating automated tests. It supports various HTTP methods, parameterization, test scripting, and CI/CD integration, making it versatile and easy to adopt.

JMeter

Originally designed for load testing, JMeter has also become a go-to for functional API testing. It supports many protocols and offers tools for creating test plans, running tests, and analyzing results, making it a solid choice if you’re looking to test how your API performs under different loads.

SoapUI

If you’re working with SOAP or REST APIs, SoapUI is a comprehensive tool with strong support for both. It has a graphical interface for functional, security, and performance testing and offers options for scripting and automation, making it a well-rounded choice.

Katalon Studio

Katalon Studio supports both API and UI testing, providing an intuitive interface, built-in keywords, and integrations with various tools. It’s beginner-friendly but also powerful enough for experienced testers, so it’s a flexible choice if you’re looking to test both APIs and UIs in one place.

Each of these tools has its own strengths, so consider what you need most—whether it’s a focus on security, automation, or load testing—to find the right fit for your project. Ultimately, the right set of tools can make API testing more efficient and thorough, testing APIs from every possible angle.

Best Practices for API Testing

API testing is essential for building reliable applications, and following a few best practices can make a big difference in your testing process. Here are some tips to keep your API testing efficient, thorough, and effective:

Define Clear Objectives and Scope

Before diving into testing, clarify what you want to achieve. Are you testing for performance, security, or functionality? Defining your objectives and the scope of your testing helps you focus on critical areas and ensures you don’t miss any key aspects.

Use a Standardized Test Case Template

Having a consistent template for test cases helps keep everything organized and easy to follow. Include sections for objectives, endpoints, parameters, expected outcomes, and actual results. A clear template makes it easier for others to understand your test cases and also simplifies test maintenance.

Be Thorough

Thoroughly test all aspects of your API to ensure complete functionality and reliability. This involves validating each endpoint's behavior with various input parameters and HTTP methods. To assess the API's error handling and data validation capabilities, perform API testing with various test scenarios, including boundary conditions and edge cases.

Isolate with Mocking

Use mocks to simulate external dependencies, like databases or third-party services. This allows you to focus solely on the API without external factors interfering. Mocking also makes it easier to isolate and test specific functionality without relying on systems that may not always be available.

Automate Whenever Possible

While manual API testing can be useful in certain situations, it's best to automate API test cases whenever possible to save time, reduce human error, and enable continuous testing. Set up automated test cases using tools like Postman, REST-assured, or StackHawk and integrate them into your CI/CD pipeline. This way, you can run tests consistently and catch issues early.

By following these best practices, you can make sure your API testing is thorough, consistent, and effective. These practices help you catch potential issues sooner, improve software quality, and deliver a more reliable experience to your users.

Overcoming Challenges in API Testing

API testing can be tricky, with some unique challenges that come up along the way. Here are a few common issues you might face—and some practical tips to overcome them:

By being aware of these challenges and taking steps to address them, you can make your API testing process smoother and more effective. In the end, these efforts go a long way in ensuring a stable, secure, and high-quality API.

Conclusion

API testing is a critical part of delivering quality software. By thoroughly testing APIs throughout the development process, you can catch and fix potential issues early, cutting down on development costs and helping ensure a smooth, reliable experience for your users. As you build API testing into your workflow, keep refining your strategies, exploring new tools, and staying ahead of emerging security threats.

Enhance your API security testing with StackHawk. Its user-friendly platform and seamless integration make incorporating dynamic application security testing (DAST) into your development workflow easy. Sign up today for a free trial and begin testing your APIs for the OWASP API Top 10 within minutes.

Understanding and Protecting Against API4: Unrestricted Resource Consumption

StackHawk

According to OWASP API Security Top 10, unrestricted resource consumption is one of the most common API security vulnerabilities. This vulnerability occurs when API requests consume resources such as CPU, memory, disk space, or network bandwidth without proper limitations. This can lead to many problems, including denial-of-service (DoS) attacks, performance degradation, and increased costs.

In this blog, we'll look into what makes this vulnerability so dangerous and discuss real-world examples of the damage it can cause. We'll also share practical strategies to help you protect your APIs and keep your data and systems safe.

What is Unrestricted Resource Consumption?

Unrestricted resource consumption attacks, much like leaving essential resources freely accessible without any limitations, can lead to overconsumption and potential depletion of vital system assets. This lack of control over resource usage can cause disruptions or system failures.

For example, an API endpoint that allows users to download large files without proper restrictions on the number or size of API requests could be exploited. A malicious user or a poorly designed script could repeatedly request substantial files, monopolizing bandwidth and potentially causing the server to crash. This illustrates the core problem: unrestricted resource consumption, especially when a single API client request can excessively consume resources, allowing attackers to misuse system resources.

Identifying Unrestricted Resource Consumption Vulnerabilities

Identifying unrestricted resource consumption vulnerabilities requires a thorough and multi-faceted approach. Begin with a comprehensive code review, focusing on endpoints that handle resource-intensive operations, like file uploads, downloads, or complex calculations. Even a single API request to these endpoints can cause excessive resource use if not managed correctly. Ensure these endpoints have strong input validation, rate limiting, and resource quotas to prevent abuse.

Complement manual reviews with automated testing tools like fuzzers and dynamic application security testing (DAST). These tools expose your API to various requests, including unexpected inputs, to identify endpoints that may fail under heavy load or unusual conditions. This testing can uncover vulnerabilities that are not visible during normal use.

Continuous monitoring is crucial. Track your system’s resource usage with vigilant observation and logging. Sudden spikes in CPU, memory, or network usage could indicate an attack, a fault in a client, or an inefficient request. Detailed logs provide crucial insights into the source of these issues, allowing for quick response and resolution.

What are the Causes of Unrestricted Resource Consumption?

Unrestricted resource consumption vulnerabilities often arise from a combination of factors related to API design, implementation, and configuration. Some common causes include:

Lack of Input Validation and Sanitization

Failing to validate and sanitize user input can make applications vulnerable to malicious or malformed requests, such as oversized payloads, unexpected data types, or commands that trigger resource-intensive operations. This can degrade performance, cause crashes, and enable attacks like SQL injection or denial-of-service. Implementing robust input validation and sanitization helps prevent these issues and ensures that only valid data is processed.

Missing or Inadequate Rate Limiting

Without rate limiting, clients can send unlimited requests in a short time, which can overwhelm the server, degrade performance, or cause outages. This lack of control also opens the door to denial-of-service attacks and can lead to unexpected costs from excessive resource usage. Implementing effective rate limiting helps maintain system stability and prevents these issues.

Unbounded Loops or Recursion

Code with unbounded loops or recursion can consume excessive CPU and memory, leading to performance issues, crashes, or system failure, especially when triggered by malicious input. These vulnerabilities can be exploited for denial-of-service attacks. To prevent this, set limits on loops and recursion, validate inputs, and monitor resource usage.

Misconfigurations or lack of resource quotas

Incorrectly set resource limits or the absence of quotas can allow clients to consume excessive CPU, memory, or bandwidth, leading to performance degradation, outages, and higher costs. This unrestricted access makes systems more vulnerable to abuse, including denial-of-service attacks. Properly configuring resource limits and monitoring usage can prevent these issues.

Unrestricted resource consumption vulnerabilities often stem from a lack of proper resource management controls within the API, allowing clients to consume system resources without limitations or oversight.

Examples of an Unrestricted Resource Consumption Vulnerability

Let’s explore some examples to demonstrate how attackers can exploit unrestricted resource consumption in different applications and understand the common pitfalls leading to these vulnerable patterns.

Example 1: No Rate Limiting

In this example, an API endpoint allows unlimited requests without any rate limiting, which can lead to excessive resource consumption.

The /expensive-operation endpoint returns a large dataset every time it is called. There is no limit to the number of requests a client can make, leading to potential excessive resource usage.

Example 2: Unlimited Data Uploads

This example shows an API that allows clients to upload data without any restrictions on the size or number of uploads, which could overwhelm server storage or bandwidth.

The /upload endpoint does not enforce any limits on the size of the file being uploaded or the frequency of uploads. An attacker could exploit this to fill the server’s disk space or excessively consume bandwidth.

These examples illustrate how easily vulnerabilities from unrestricted resource consumption can occur when APIs lack proper controls. To protect your API, it is essential to implement rate limits, validate inputs, and set quotas.

Understanding the Impact of Unrestricted Resource Consumption Vulnerabilities

Unrestricted resource consumption vulnerabilities can severely impact your API server and overall system. The most immediate effect of such attacks is often performance degradation due to resource exhaustion. As attackers consume excessive resources, legitimate users may experience slow response times, timeouts, or complete service unavailability. Picture a popular e-commerce website grinding to a halt during a peak sales season because a bot exploited a vulnerability to request product data, overwhelming the target system. The resulting loss of revenue and customer trust can be devastating.

Beyond causing performance issues, unrestricted resource consumption can make systems vulnerable to Denial-of-Service (DoS) attacks. In a DoS attack, the attacker exhausts the target system’s resources, making it inaccessible to legitimate users. An unrestricted resource consumption vulnerability allows the attacker to exploit this weakness. The financial implications of unrestricted resource consumption can be significant. Cloud providers often charge based on resource usage. An attack or unintentional excessive usage due to a vulnerability can lead to a sudden and unexpected surge in your cloud bill.

Prevention and Mitigation Strategies

To prevent unrestricted resource consumption, implement a multi-layered strategy. Start with robust input validation and sanitization—treat all user input as potentially harmful. This step ensures incoming data meets expected formats, sizes, and types.

Enforcing rate limits and throttling on your API endpoints controls the number of requests a client can make within a specific timeframe, preventing abuse and keeping your system from being overwhelmed, similar to a toll booth managing traffic flow. Establish clear resource quotas to limit the amount of resources each client can consume, ensuring fair usage for all users.

Regular code reviews and security audits are essential for maintaining a secure API. These reviews identify potential vulnerabilities before they become problems. Incorporate automated testing tools and fuzzing to rigorously test your API under various conditions, including heavy loads and unexpected inputs. Implement real-time monitoring and anomaly detection to track resource usage and identify unusual patterns.

By adopting these strategies, you significantly reduce the risk of unrestricted resource consumption vulnerabilities and bolster the security and resilience of your API.

Conclusion

Unrestricted resource consumption vulnerabilities can significantly compromise API security and performance, leading to issues such as denial-of-service attacks and increased cloud costs. To mitigate these risks, it is essential to adopt a multi-layered defense strategy that includes robust input validation, enforcing rate limits, setting resource quotas, and continuous monitoring. By understanding these vulnerabilities and proactively implementing security measures, you can protect your APIs against resource exhaustion attacks, ensuring smooth and reliable system operation.

By using StackHawk to proactively detect and address OWASP API Security Top 10 vulnerabilities, you can minimize the risks stemming from these common API threats. Sign up for a 14-day free trial of StackHawk today to experience the difference StackHawk makes in detecting vulnerabilities and API security issues outlined in the OWASP API Top 10.

Introducing Oversight: Providing a Birds-Eye View of API Security

Brian Erickson

As organizations grow and their application portfolios expand, keeping track of security testing can become a daunting task. StackHawk’s mission is to empower teams to take control of their application security with tools that scale alongside them. With the launch of our new Oversight feature, we're making it easier for teams to manage their application security at scale, providing a streamlined view of their applications and security status across environments. Now live and ready for use, Oversight delivers a comprehensive, top-level view to help teams stay ahead of potential risks and maintain a strong security posture.

A New View for a Growing List of Applications

In the past, StackHawk’s Applications list worked well for smaller teams but became unwieldy for larger organizations managing multiple teams and hundreds of applications. The new tabular view is designed with scalability in mind, allowing users to see all their applications at a glance. With improved filtering, sorting, and search capabilities, security teams can now quickly drill into specific applications or environments to monitor their security status.

Here’s what the new Applications List delivers:

Tabular Display: This clean, detailed list of all your applications includes key metrics such as the last scan date, findings from the last scan, and scan duration. These columns can be sorted to help you identify trends, like the applications with the most critical findings or those with longer scan times.
Recent Commits: By integrating with GitHub, the Applications List also displays recent commits, giving teams insight into how actively the codebase is changing. This helps teams determine whether their scan frequency is keeping up with code updates.
Filters and Search: With the expanded filtering options, users can filter applications by teams, environments, or other custom facets. The search bar allows for quick access to specific applications, and a clear indicator shows when filters are active to ensure you're always aware of the view you’re seeing.

Oversight: A Proactive Approach to Security

On top of the new Applications List, StackHawk is introducing Oversight, a feature designed to provide teams with a top-level view of their application security program. Oversight aggregates key security data across all applications, making it easier to see the big picture.

Here’s how Oversight supports security teams:

Scan Frequency Monitoring: Oversight flags applications that haven’t been scanned in the last 30 days, ensuring that security teams are always aware of gaps in coverage. The visual dashboard helps identify applications where scan activity may be slipping, so nothing gets missed.
Total Findings Overview: The oversight panel highlights **outstanding findings** across all applications. This makes it easy for teams to prioritize remediation efforts and track which applications are most vulnerable.
Attack Surface Insights: For organizations leveraging StackHawk’s API Discovery feature, Oversight provides a view of the attack surface coverage, helping teams ensure they’re testing all critical areas of their applications, including APIs.

Enhancing Collaboration and Flexibility

The new Oversight feature is designed to fit seamlessly into your organization’s workflow, offering flexibility and customization options. Based on feedback from our customers, we’ve built the following capabilities:

Environment-Specific Insights: See scan results and findings for each environment (e.g., development, QA, production) to better track the security status across your application lifecycle.
Contextual Filters: Filter your applications by teams, environments, or other attributes, so you can focus on the parts of your organization that need the most attention.

What’s Next?

We're excited to announce that Oversight is now live and available to all StackHawk customers. With this new feature, we continue our commitment to delivering developer-first, scalable security tools that make it easier for organizations to manage their application security programs, no matter how large their application portfolios grow.

Try out Oversight today and experience the benefits of streamlined application management and enhanced security visibility. This is just the beginning—we plan to continue building on Oversight over the coming months, adding new capabilities to further support your security efforts. We’d love to hear how these features are helping your team stay on top of security testing. If you have any feedback or suggestions, we're always here to listen. Try StackHawk today – 14 day free trial.

Learn more about Oversight by visiting our solutions page.

API Discovery vs. API Monitoring: Why Proactive API Security is the Future

StackHawk

As organizations increasingly depend on APIs to drive their applications—especially with AI enabling developers to ship code up to 200x faster—the demand for strong API security solutions has never been more critical. However, not all API security methods are equally effective. One of the most pressing and sometimes overlooked aspects of API security is ensuring that all APIs are accurately documented and protected. Automatic API discovery is emerging as a critical solution for this gap, efficiently identifying and documenting APIs with API portfolios big and small. Also within this realm is the tools associated with API monitoring. However, which should be prioritized, and where does each solution fit?

The debate between API discovery and API monitoring is gaining traction, with proactive security solutions like StackHawk leading the charge in shifting the industry’s approach. In this blog, we will look at the different aspects of each solution, the use cases they cover, and how you should use them to secure your APIs. Let's get started by looking more in-depth at both solutions.

Understanding API Discovery and API Monitoring

API monitoring has long been the standard approach to API security. It involves tracking and analyzing API traffic in production environments, often using tools that monitor for anomalies, unauthorized access, and other potential threats. While monitoring is essential, it tends to be reactive—identifying issues only after they occur. This late-stage detection can leave your organization vulnerable to attacks that could have been prevented with earlier intervention.

On the other hand, automated API discovery helps identify APIs as they are created, even before they reach production. This method allows for earlier detection of security vulnerabilities, enabling organizations to address potential threats before they can be exploited. In the world of API security, this proactive stance is becoming increasingly necessary, especially with the rapid proliferation of APIs in today’s interconnected applications.

Unlike API monitoring, which is generally automated, manual API discovery exercises are possible. Manual API discovery, a hands-on approach where teams manually track and document APIs, is more suitable for smaller environments. However, it presents challenges in larger settings, such as being time-consuming, error-prone, and requiring significant human effort and knowledge that might not always be up-to-date. In most cases, using API discovery tools to automate API discovery will be the most efficient way to ensure all APIs are discovered and documented as part of your attack surface.

Why Proactive and Automatic API Discovery Matters

Continuous and automated API discovery is a critical piece of security for a few reasons:

Immediate Onboarding and Integration One key advantage of proactive API discovery is the speed and ease of onboarding. Solutions like StackHawk enable organizations to get started in just 15 minutes and integrate seamlessly with their existing development processes, compared to the months-long integrations required by traditional API monitoring tools. Systematically reviewing API endpoints ensures security and compliance from the outset.
Comprehensive Coverage Before Production Proactive API discovery doesn’t just focus on what’s already in production. It identifies APIs before they go live, including internal APIs, B2B APIs, and those that may otherwise fly under the radar. This includes managing API sprawl by connecting discovered APIs directly to the teams responsible for their development, ensuring that security is baked in from the start. By covering 30% of your applications with this approach, you can catch vulnerabilities before they see the light of day.
Source Code Driven Accuracy Unlike traditional API monitoring tools that rely on production traffic, StackHawk’s approach is driven by source code analysis. This bottoms-up method provides far more accuracy, allowing you to identify and fix issues at the code level before they become larger problems in production. This shift-left approach—discovering APIs as they are created, not just after they are deployed—ensures early and precise vulnerability detection.
Extensive API Type Compatibility StackHawk supports a wide range of API types, including REST, GraphQL, and gRPC. It also excels at identifying shadow APIs—those that exist in your environment but are unknown to your security teams—and zombie APIs, which are inactive and have no recent development activity. By addressing these hidden vulnerabilities, you can secure your API ecosystem more comprehensively.

The Competitive Edge: Why StackHawk is Different

While traditional API monitoring tools like Noname, Salt, and Traceable focus on monitoring production traffic, StackHawk takes a proactive approach with shift-left API discovery. This methodology identifies and secures APIs from the moment they are created, minimizing risks before deployment. This proactive stance is especially crucial in the age of AI, where the speed of development makes it impossible to rely solely on reactive security measures.

Managing the entire API lifecycle from creation to retirement enables organizations to develop, monitor, test, and secure APIs efficiently, addressing the complexities involved in managing numerous internal and external APIs in today's IT infrastructures.

Infrastructure Flexibility: StackHawk’s solution requires no infrastructure changes, offering a one-click deployment that immediately begins discovering APIs. Additionally, StackHawk covers both internal and B2B APIs—an area where many competitors fall short.

Attack Surface Discovery (ASD) vs. API Discovery: StackHawk’s approach goes beyond simple API discovery by offering a complete attack surface discovery and testing solution. This ensures that your entire digital footprint is secured, not just the APIs you know about.

Why CISOs Should Care

In an era where it only takes one breach to cause significant damage, proactive API discovery is no longer a luxury—it’s a necessity. CISOs need full visibility into their organization’s attack surface, and StackHawk’s proactive API security solution provides just that. Accurate API documentation supports security and compliance efforts by providing detailed information about APIs, including their purposes and security measures. By identifying and securing APIs before they reach production, you can prevent vulnerabilities from ever becoming a threat.

The Role of API Management in API Security

Although API discovery and monitoring are key parts of the API security puzzle, they still sit under the larger umbrella of API management. It serves as the backbone for identifying, cataloging, and securing all existing APIs within an organization, including shadow APIs, zombie APIs, and rogue APIs. By leveraging advanced API discovery tools, organizations can gain comprehensive visibility into their API usage and traffic, which is crucial for detecting vulnerabilities and mitigating security risks proactively.

API management is not just about keeping track of APIs; it involves using automated tools to streamline API discovery processes, thereby reducing the risk of human error and enhancing the accuracy of API documentation. This ensures that APIs are not only secure but also well-documented and compliant with regulatory requirements. Unfortunately, most API management solutions do not extensively implement API discovery like StackHawk does, with the capability to scan source code and look for these potentially hidden endpoints.

A key component of API management is implementing API gateways and management tools. These tools monitor and control API traffic, enforce security policies, and apply rate limiting to prevent overloading. This multifaceted approach helps prevent unauthorized access and significantly reduces the risk of security breaches. This is a cornerstone of API security, but if APIs are not documented, they can easily fall outside of the protection of an API management solution.

By leveraging API management and StackHawk's API discovery tools, organizations can ensure continuous API discovery processes that identify and prioritize security risks. By doing so, organizations can take proactive measures to secure their APIs before they become targets for malicious actors. This proactive stance is essential for maintaining a robust security posture in an increasingly interconnected digital landscape.

Effective API management encompasses several critical activities:

API Discovery: Identifying and cataloging all existing APIs, including shadow APIs, zombie APIs, and rogue APIs.
API Documentation: Creating and maintaining accurate and up-to-date documentation for all APIs.
API Security: Implementing security measures to protect APIs from unauthorized access and security breaches.
API Traffic Management: Monitoring and controlling API traffic to prevent overloading and unauthorized access.
API Compliance: Ensuring that APIs comply with regulatory requirements and industry standards.

By implementing these activities, organizations can ensure that their APIs are secure, well-documented, and compliant with regulatory requirements. This reduces the risk of security breaches and improves the overall security and compliance of their APIs.

Adopting effective API management practices includes ensuring that comprehensive API discovery is part of your playbook. By ensuring that every API is documented and covered under an API management solution, organizations can enhance the security and compliance of their APIs, reduce the risk of security breaches, and ensure that their APIs comply with regulatory requirements.

The Future of API Security

The need for proactive, shift-left security solutions will only grow as the API landscape expands. API discovery offers a forward-looking approach to API security that goes beyond the limitations of traditional API monitoring. With StackHawk, you’re not just monitoring APIs—you’re discovering and protecting them from the moment they are created, ensuring that your security posture is as advanced as the threats you face.

Get Started with StackHawk for Free

Top Tools for Effective Application Security Scanning

Matt Tanner

Keeping up with every vulnerability that could impact your code and applications can be a lot of work. Creating an application comes first for most developers, and securing it becomes a secondary priority. It's no surprise since many teams, especially in older organizations, approach web-app/application security testing in the later phases of development, and a completely separate team handles this testing. Enter the realm of modern development practices, and you'll see that many development and AppSec teams are using automated tooling to make security an automated and highly prioritized part of the SDLC. Testing earlier and more often.

This shift-left approach requires many tools to create a holistic security testing stack. Within this stack, a plethora of various testing tools likely exist. So which ones do you choose? This blog will cover some of the top tools to help you build a modern and effective application security testing stack. Let's begin by digging into the fundamentals of security testing.

Introduction to Application Security Scanning

What is Application Security Scanning?

At the highest level, application security scanning identifies and addresses security vulnerabilities within web applications. Much of the time, developers and security teams can scan web-apps using automated tools to uncover potential security risks. By integrating application security scanning into the software development life cycle, organizations can ensure that their web applications are secure from the ground up, from when the first line of code is written through to the app running in production.

Importance of Application Security Scanning

Security breaches and issues can be costly in many ways. Security can positively or negatively impact an application, so application security scanning is a crucial component of any comprehensive security strategy. Here are a few factors that make application security scanning so critical:

Protection Against Cyber Attacks: By identifying and fixing vulnerabilities early in the SDLC, you can protect your applications from being exploited by malicious actors.
Compliance: Many security regulations and standards (such as PCI-DSS, GDPR, and ISO-27001/ISO-27002) require regular security assessments to ensure your company remains compliant. Application security scanning helps ensure that your web applications comply with these requirements.
Proactive Risk Management: By addressing vulnerabilities before they are exploited, you can significantly reduce the risk of data breaches and other security incidents.

Web Application Security Risks

Common Web Application Vulnerabilities

Web applications are often targeted by attackers due to various common vulnerabilities. Understanding these vulnerabilities is the first step in protecting your applications. Some of the most frequent vulnerabilities include:

Cross-Site Scripting (XSS): This occurs when attackers inject malicious scripts into web pages viewed by other users, potentially stealing session tokens or other sensitive information.
SQL Injection: Attackers exploit this vulnerability by inserting malicious SQL queries into input fields, which can lead to unauthorized access to the database.
Cross-Site Request Forgery (CSRF): This tricks users into executing unwanted actions on a web application where they are authenticated, leading to unauthorized actions.
Remote Code Execution (RCE): This vulnerability allows attackers to run malicious code remotely on a server or system, potentially taking full control of the targeted application or infrastructure.
Local File Inclusion (LFI): In this attack, malicious actors exploit vulnerable code to include unauthorized files from the local server, potentially exposing sensitive information or executing unintended scripts.

Types of Application Security Testing

To ensure comprehensive security, it’s important to understand the different types of application security testing. Each type offers unique benefits and focuses on different aspects of your application’s security.

Static Application Security Testing (SAST)

Static Application Security Testing (SAST) solutions, such as Snyk and GitLab, involve analyzing your source code for security vulnerabilities. This type of testing looks specifically at how your application is designed and coded and does not require it to be running.

Benefits:

Early Detection: Identifies security flaws early in the secure software development process, allowing developers to fix issues before the code is deployed.
In-Depth Analysis: Provides a thorough examination of the codebase, helping to ensure that security is built into the application from the start.

Dynamic Application Security Testing (DAST)

Dynamic Application Security Testing (DAST) platforms, such as StackHawk, involve testing your web applications for security vulnerabilities while they are running. This type of testing simulates attacks and exploitation on the live application.

Benefits:

Real-World Simulation: By mimicking the expected behavior of an attacker, DAST scans help identify vulnerabilities as if they have been discovered by a threat hunter or attacker
Comprehensive Coverage: Detects security issues in the running environment, including configuration errors and runtime vulnerabilities that might be missed by SAST tools.

Interactive Application Security Testing (IAST)

IAST combines elements of both SAST and DAST to provide a more comprehensive analysis of your applications. It involves analyzing source code and testing running applications for security vulnerabilities.

Benefits:

Holistic Approach: Offers a comprehensive view of security by combining static and dynamic analysis techniques.
Real-Time Feedback: Provides immediate feedback on security vulnerabilities, helping developers to address issues more quickly.

Web Application Scanning Tools Comparison

Choosing the right web application scanning tool is crucial for effective security. Below you can find a comparison of some of the most popular tools available, highlighting their key features and benefits.

StackHawk

OWASP Top Ten: StackHawk's DAST scanner detects vulnerabilities in the OWASP Top Ten, providing coverage of the most critical security risks in modern web applications.
Simple Setup: StackHawk is designed to be easy to set up and configure, reducing the barrier to entry for incorporating security testing into the development workflow.
Collaboration Tools: It can integrate with collaboration tools like Jira and Slack, facilitating communication and tracking of security issues within development and operations teams.

Qualys Web Application Scanning

Comprehensive Scanning: Qualys offers an in-depth analysis of web applications, identifying a wide range of vulnerabilities.
Compliance Assurance: Helps ensure that your web applications comply with security regulations and standards.
Detailed Reporting: Provides detailed reports that help prioritize vulnerabilities based on risk, making it easier to address critical issues first.

Tenable Web App Scanning

User-Friendly Interface: Tenable is known for its ease of use, making it accessible for both beginners and experienced security professionals.
Effective Vulnerability Detection: Identifies security vulnerabilities efficiently, helping to protect web applications from potential threats.
Regulatory Compliance: Assists in meeting various compliance requirements by providing thorough security assessments.

Other Web Application Scanning Tools

OWASP ZAP: An open-source tool that offers a variety of features for finding security vulnerabilities in web applications. It’s especially popular among developers and security enthusiasts due to its flexibility and extensive documentation.
Burp Suite: A comprehensive platform for web application security testing, Burp Suite is known for its powerful scanning capabilities and its suite of tools designed for penetration testing.
Nuclei: A fast, customizable tool for finding security vulnerabilities using community-contributed or custom self-built templates. Nuclei is highly flexible and suitable for a range of security testing scenarios, from simple scans to complex assessments.

Using Web Application Scanning Tools

When selecting security tools, there are several factors which might impact your tool selection . These include the experience level of your internal security team and whether you are fully utilizing any existing tools that you already pay for. It’s crucial to match the tools with your specific security testing requirements and ensure they integrate well with your current development and operations workflows.

Scalability to support future growth, the quality of support and documentation, and the frequency of updates to address emerging threats are also important. Additionally, consider the overall cost-effectiveness relative to your security budget. The chosen tool should be easy to use, have a manageable learning curve, and integrate seamlessly into your team’s daily operations to avoid significant disruptions. Below are some additional factors to consider:

No Setup Required: Many modern web application scanning tools require minimal setup, allowing you to start scanning immediately. This is particularly beneficial for teams that need to quickly implement security measures.

Scheduling Scans: Most tools offer the ability to schedule scans to run automatically. Regularly scheduled scans help ensure that your web applications are continuously monitored for new vulnerabilities.

API Access and Integrations: Many scanning tools provide API access and can be integrated with other security systems and tools. This integration capability allows for streamlined workflows and comprehensive security management.

Web Application Scanning Reports and Results

Interpreting scan results and acting on them is a crucial part of maintaining the security of your web applications. This section will guide you through understanding scan results, prioritizing vulnerabilities, and implementing remediation strategies.

Understanding Scan Results

Vulnerability Details: Each detected vulnerability will include a description, potential impact, and recommended remediation steps.
Severity Levels: Vulnerabilities are typically categorized by severity (e.g., critical, high, medium, low). This should be used as a guide to help you prioritize which issues to address first.
Affected Components: Reports will indicate which parts of your application are affected, helping you pinpoint the exact locations of vulnerabilities in your codebase and applications.

Prioritizing Vulnerabilities

Not all vulnerabilities pose the same level of risk. It’s important to prioritize vulnerabilities based on their potential impact and the likelihood of exploitation. Consider the following factors:

Severity: Focus first on critical and high-severity vulnerabilities that could have the most significant impact if exploited.
Exposure: Prioritize vulnerabilities in publicly accessible parts of your application, as these are more likely to be targeted by attackers.
Business Impact: Consider the potential business impact of each vulnerability, including potential data breaches, downtime, and regulatory compliance issues.

Remediation and Mitigation

Addressing identified vulnerabilities promptly is crucial for maintaining application security. Here are some strategies for effective remediation and mitigation:

Fix the Code: Work with developers to fix vulnerabilities in the source code, following secure coding practices.
Apply Patches: Ensure that all software components, including third-party libraries, are up-to-date with the latest security patches.
Implement Workarounds: In some cases, temporary workarounds may be necessary until a permanent fix can be applied. For example, you might restrict access to a vulnerable feature or apply configuration changes to mitigate the risk.

Web Application Security for DevOps

Integrating web application security into your DevOps pipeline ensures that security is a continuous, integral part of the development process. This approach, often referred to as DevSecOps, aims to bridge the gap between development and security teams, fostering collaboration and automating security testing. Here’s how you can incorporate web application security into your DevOps practices.

Integrating with DevOps Pipelines

To ensure that security checks are performed consistently and efficiently, integrate web application scanning tools directly into your DevOps pipelines. Here’s how:

Continuous Integration (CI): Incorporate security scans as part of the CI process. This means that every time code is committed or merged, automated security scans are triggered, identifying vulnerabilities early.
Continuous Deployment (CD): Ensure that security scans are part of the deployment process. This ensures that any vulnerabilities are caught before the application is released to production.
Automated Testing: Automate security tests alongside functional and performance tests. This creates a holistic testing environment where security is continuously monitored.
Immediate Feedback: Provide developers with real-time feedback on security issues, enabling them to address vulnerabilities promptly during the development process.

Improving Collaboration Between Dev and Security Teams

Effective communication and collaboration between development and security teams are crucial for the success of DevSecOps. Here are some strategies to improve this collaboration:

Shared Goals and Metrics: Establish common goals and metrics for both teams. For example, aim to reduce the number of vulnerabilities or ensure all critical issues are addressed within a certain timeframe.
Cross-Functional Training: Encourage cross-functional training so that developers understand security principles and security teams are familiar with the development process.
Collaborative Tools: Use collaborative tools and platforms that allow both teams to share information, track vulnerabilities, and monitor remediation efforts.

Web Application Security for Cloud Security

As organizations increasingly adopt cloud-based services, ensuring the security of web applications in the cloud becomes paramount. This section discusses how to effectively scan, secure, and protect cloud-based web applications.

Scanning Cloud-Based Web Applications

Cloud environments introduce unique challenges and opportunities for web application security. Here’s how to approach scanning cloud-based applications:

Cloud-Native Tools: Use cloud-native security tools provided by your cloud service provider (CSP), such as AWS Inspector, Azure Security Center, or Google Cloud Security Command Center. These tools are designed to integrate seamlessly with your cloud environment.

Regular Scans: Schedule regular security scans to continuously monitor your cloud-based applications. This helps identify and address vulnerabilities as they arise.
Configuration Checks: Ensure that your cloud configurations are secure by regularly scanning for misconfigurations, which are a common source of security vulnerabilities in the cloud.

Ensuring Cloud Security Compliance

Compliance with cloud security regulations and standards is crucial for protecting sensitive data and avoiding penalties. Here are some steps to ensure compliance:

Understand Regulations: Familiarize yourself with relevant cloud security regulations and standards, such as GDPR, HIPAA, and PCI DSS. Each has specific requirements for data protection and security.
Automated Compliance Checks: Use automated tools to check for compliance with these regulations. Many CSPs offer built-in compliance checks and reporting tools.
Continuous Monitoring: Implement continuous monitoring to ensure ongoing compliance. This includes real-time alerts for any compliance violations and regular audits.

Protecting Cloud-Based Data

Protecting data in the cloud requires a multi-faceted approach. Here are some best practices:

Data Encryption: Encrypt data both at rest and in transit. This ensures that even if data is intercepted or accessed without authorization, it remains unreadable.
Access Controls: Implement strict access controls and use identity and access management (IAM) tools to ensure that only authorized users can access sensitive data.
Regular Backups: Perform regular backups of your data to prevent loss due to breaches, failures, or other incidents. Ensure that backups are also securely stored and encrypted.

By effectively scanning cloud-based web applications, ensuring compliance with relevant regulations, and protecting cloud-based data, you can significantly enhance the security of your applications in the cloud.

Web Application Security for Enterprise Security

Enterprise environments present unique challenges and opportunities for web application security. With larger and more complex infrastructures, it’s crucial to scale security measures effectively and manage risks across the entire organization. Here’s how to approach web application security in an enterprise setting.

Scaling Web Application Security

Centralized Security Management: Use centralized tools for monitoring and managing security across all web applications.
Automated Security Processes: Automate tasks like scanning, patch management, and compliance checks to handle scale efficiently.
Resource Allocation: Ensure security teams have the necessary tools, personnel, and training.

Managing Web Application Security Risks

Risk Assessment: Regularly identify and evaluate potential security threats.
Risk Prioritization: Focus on the most critical vulnerabilities first.
Incident Response Plans: Develop and test plans for quick and effective incident responses.

Ensuring Enterprise-Wide Security

Security Training and Awareness: Regularly train employees on security best practices and threat recognition.
Secure Development Practices: Integrate secure coding practices and use SAST and DAST tools.
Continuous Monitoring and Improvement: Monitor threats in real time and use insights to improve security measures.

Next Steps for Improving Web Application Security

Implement a Web Application Scanning Tool: Choose a tool that fits your organization's needs and integrate it into your security strategy.
Integrate Security into DevOps Pipelines: Ensure security is a continuous part of the development process by incorporating automated scans and real-time feedback.
Improve Collaboration: Foster better communication and collaboration between development and security teams to ensure security is built into every stage of the application lifecycle.

Conclusion

Application security scanning is essential for identifying and addressing vulnerabilities in web applications using automated tools. By employing SAST, DAST, and IAST, we can achieve a comprehensive analysis through the combination of static and dynamic testing. Effective scanning with tools like Qualys, Tenable, OWASP ZAP, Burp Suite, and Nuclei ensures compliance and protects against cyber threats.

When it comes to utilizing DAST for web applications and the APIs that power them, StackHawk is a great platform to adopt. StackHawk's modern DAST platform empowers developers and AppSec teams to easily test their applications and remedy any vulnerabilities with customized insights and easy-to-follow reports. Scanning applications locally or in CI/CD gives flexibility for developers to test their code manually as they write it and automatically when pushed into source control. Want to try out StackHawk for yourself? Sign up today for a 14-day free trial.

What is Cloud API Security? A Complete Guide

StackHawk

What is API Security?

API Security is a general term that refers to the practices and protocols designed to protect your API (or Application Programming Interface) from API threats. Security has a lot of elements and is best thought of as a comprehensive strategy.

It's a delicate balance for security professionals as they seek to mitigate risks like data breaches and unauthorized access while ensuring that legitimate users experience no obstacles.

This article will delve into key principles for reinforcing API security, tackling challenges like blocking attacks and strengthening vulnerabilities, and focusing on maintaining seamless data exchange and support for authorized users.

What is Cloud API Security

Cloud APIs carry unique risks and challenges, requiring attention to the services they offer and the complex cloud environments they operate within. To add another layer of complexity, Cloud APIs often involve multiple stakeholders and third-party services, which can increase the overall risk and complexity of the security posture.

Cloud API protection faces common risks like compromised user authentication and authorization alongside unique threats from external dependencies, including implementation flaws, unauthorized APIs, credential leaks, and data breaches.

Effective cloud security demands specialized strategies, such as cloud-specific access controls and encryption, to prevent malicious data theft or exploitation of flaws, thorough API lifecycle management to prevent deprecation and adoption issues, and robust control over external API usage.

Key Concepts in Cloud API Security

Cloud API Security, essentially a decentralized take on traditional API Security, follows many of the same guidelines and faces similar risks in guarding against malicious activity and threats. The key difference lies in addressing these concerns across various services, both ephemeral and permanent. Let’s take a closer look at API security first.

API Security Fundamentals

In order to implement API security effectively, you'll want to keep the following fundamentals in mind:

Data Encryption

Securing data is crucial, and the best way to do this is by using strong encryption. Encryption is the process of taking data and scrambling it in a way that only trusted users with the right key can use that data. The more data you hold, the wider your attack surface, so starting with good encryption right away is key to keeping your data and APIs safe from attacks.

Data Encryption in Transit

APIs transmit data from one system to another and this data should be adequately secured during transit. Transport Layer Security, or TLS, is an industry-standard solution that can encrypt data as it's exchanged, ensuring protection from eavesdropping, tampering, and man-in-the-middle attacks. TLS is essential to protect sensitive data and ensure communication security.

Data Encryption at Rest

Once data has been transferred, it must be secured to ensure that any potential exfiltration is mitigated. In Cloud APIs, this is especially important as there's no real physical separation between data processing and storage. There are many encryption-at-rest options; choose one that's easy to maintain, as security needs constantly evolve. Authentication and Authorization Mechanisms

Protecting sensitive data is as much about securing the data as it is about securing access, ensuring only authorized users can access critical information and functions. Accordingly, implementing proper access control policies is a vital step in setting a strong security posture. There are two types of access controls in this domain - authentication and authorization.

What is Authentication?

Authentication is making sure that a user is who they say they are. If a user says that they are an admin named AdminUser01, the system must ensure that this person is who they say they are. This can take a variety of forms, including the use of data and hardware keys or authentication tokens that establish the user is accessing the system in a way that is similar to how it has been accessed before. This can also include things such as passwords and other factors.

What is Authorization?

Authorization, on the other hand, is proving that a user has the right to access what they are trying to access. This can be accomplished through a variety of mechanisms, including role-based access control, object-level access control, and more. Broken object-level authorization (BOLA) and broken function-level authorization (BFLA) are very common issues, even in otherwise secure authorization implementations - this is a great example of the fact that authorization should be comprehensive and complimentary. Good enough in one area is not good enough for the whole system.

Fortunately, there are many authorization solutions in the market, and open authorization standards such as OAuth offer a relatively plug-and-play solution at scale.

Multi-factor Solutions

It's crucial to avoid single points of failure in security systems. Authorization should encompass knowledge, possession, and inherent traits of the user, known as multi-factor authentication.

API Security Risks and Threats

Common API Security Threats

In API security discussions, it’s essential to examine the types and scope of vulnerabilities.. First, there are issues of authorization and authentication. These issues stem from inadequate user control and overly permissive access, leading to data and function exposure.

Next, there is the general category of data integrity and process security. Injection attacks, such as SQL injections and cross-site scripting (XSS) issues, can be used to exploit vulnerabilities in APIs. Injection attacks can exploit user input to bypass authentication, threatening API security despite protective measures. Man-in-the-middle attacks can be used to hijack interactions, infiltrating the system with otherwise legitimate traffic.

There are also major concerns with misconfiguration and vendor dependency. Misconfiguration can undermine even the most secure systems, rendering strong authentication useless. Often, this isn't due to your actions; choosing a poorly performing vendor can be as detrimental as implementing insecure systems.

With so many risks, how can developers begin to form a plan for tackling this issue?

OWASP Top Ten

Luckily, The Open Worldwide Application Security Project, or OWASP, has put together a list called the OWASP Top Ten. While this list is not exhaustive, the OWASP API vulnerabilities list is nonetheless representative of the most common threats to which APIs are exposed.

The OWASP Top Ten divides the most common security issues into the following categories:

A01:2021-Broken Access Control

This category of security issues includes services that have broken access control, allowing users to access data without proper security systems standing in the way.

A02:2021-Cryptographic Failures

This is when cryptographic implementations are flawed, resulting in data exposure or - in serious cases - full system compromise.

A03:2021-Injection

Injection is when data is forced into the system through transit failure, poor sanitation, etc. Attacks of this kind can expose the underlying data and systems and often come from poor external vendor integration or sanitation procedures.

A04:2021-Insecure Design

This type of issue comes from poor design processes, including the implementation or poor development paradigms, codebase structures, and security design.

A05:2021-Security Misconfiguration

This is a broad category, but it is unfortunately very common. Poor configuration can lead to even powerful solutions being rendered basically ineffective, exposing data and creating additional vectors for attacks.

A06:2021-Vulnerable and Outdated Components

This refers to using outdated or unpatched software components with known vulnerabilities. Attackers can exploit these known weaknesses if not updated or patched promptly.

A07:2021-Identification and Authentication Failures

This used to be called "Broken Authentication," but this has also been expanded to include identification issues. This category covers issues where authentication mechanisms are improperly implemented, allowing attackers to compromise passwords, keys, or session tokens.

A08:2021-Software and Data Integrity Failures

This includes vulnerabilities that occur when software updates, critical data, or CI/CD pipelines are not verified, allowing attackers to inject malicious code or manipulate data.

A09:2021-Security Logging and Monitoring Failures

This category highlights the lack of proper logging, monitoring, and alerting mechanisms that can help detect security breaches. Without these, attackers can operate undetected.

A10:2021-Server-Side Request Forgery

SSRF vulnerabilities occur when an attacker is able to induce a server-side application to make HTTP requests to an unintended destination, potentially leading to unauthorized actions or information disclosure.

Secure API Design and Development

The best way to ensure you have a good security posture is to start early. Adopting some general processes for secure API design and development is a great way to ensure a culture of security.

Secure Coding Practices

Secure coding practices baked into the application development process itself, such as input validation and error handling, can help prevent common API security threats. Ensuring that the data entering the system has been vetted and sanitized can ensure that even attacks using what seems like valid traffic can be stopped in their tracks, preventing the abuse of your internal authentication and authorization systems.

Using secure protocols, such as HTTPS and TLS, can help protect data transmitted through APIs. This ensures your data is secure in transit and can be protected from man-in-the-middle attacks that might hijack the traffic for nefarious purposes.

Be Defensive

Approaching your system with defense in mind can help create a more secure implementation for your APIs. Rate limiting and quotas can help prevent denial-of-service attacks and abuse in ways that are often invisible to the average end user, giving you a strong defensive posture from day one. Using JSON Web Tokens (JWTs) and other secure authentication mechanisms can help protect API endpoints. Pairing this with a Zero-Trust paradigm, where everything is validated and nothing is intrinsically trusted, can ensure that these systems are cross-validated and secured in their own context.

API Traffic Management and Monitoring

Managing API Traffic

A huge first step in securing your traffic is managing traffic generation. Managing traffic involves controlling and regulating the flow of requests and responses between APIs and clients, as well as using load balancers to prevent overload and distribute that traffic across services. This can prevent DDOS attacks and other attacks focused on overwhelming the system.

Implementing caching and content delivery networks (CDNs) can help improve API performance and reduce latency. In doing this, attacks that focus on overwhelming systems and forcing errors can effectively be drastically reduced in efficacy, as the potential damage done by any one attack vector is mitigated.

Monitoring Traffic

Of course, it's not good enough to just manage the traffic - you also need to monitor the API events coming into the system. Monitoring traffic involves tracking and analyzing API requests and responses to detect security threats and performance issues.

Implementing real-time monitoring and alerting can help detect and respond to security incidents quickly. In essence, if your API is a secure stronghold, monitoring is a tower by which you can survey the land and ensure your stronghold is not beset by hidden enemies.

API Discovery

Part of making sure your APIs are secure is knowing that they exist. Of course, in an ideal world we would know of every API ever built within our company. However, the reality is that manual API inventories are not always accurate or up to date, which could lead to untested and potentially vulnerable APIs within your attack surface. This is where API discovery tools can come in handy to ensure that every API, including those created maliciously or forgotten by accident, is included in testing and API security efforts. Tools like StackHawk actually do this at the code level by searching code repositories for APIs and then marking them to be tested, helping to improve security for all APIs hosted on the cloud or otherwise.

A crucial concept in cloud systems is the ephemeral nature of services and databases, which are continuously created and decommissioned. This ongoing change brings familiar API and data security challenges, along with the crucial need for compliance, accurate record-keeping, and constant awareness in a fast-paced setting.

Let’s consider credential stuffing. In a typical API, the best way to mitigate such threats is to rate limit inputs for credentials and to utilize systems that flag compromised assets. In a cloud API, however, you must be able to do this for services that are being created by the minute - sometimes numbering in the hundreds.

In the cloud environment, typical issues from the development lifecycle are significantly intensified. Weak authentication is problematic on its own, but this issue escalates dramatically when managing hundreds of microservices or data sources, complicating monitoring even further. In such an environment, poor API security posture exacerbates the problem to the nth degree.

Cloud services also typically use a wide spread of protocols and approaches. REST APIs might work closely with SOAP (or Simple Object Access Protocol) APIs, gRPC APIs, WebSockets, and much more. These services might rapidly appear and disappear, and the API risks that are inherent with such complicated systems can rapidly become even harder to track or be aware of.

To that point, cloud security is largely about making API security intrinsic to the integration and development process. Unsafe consumption can be prevented when developers are mindful of the practice. Web application and API risks can be mitigated with more secure development. Solutions deployed early on such as federated token-based authentication, can ensure the ability to properly authenticate users even when the system is incredibly complex.

Best Practices for Securing Cloud APIs

When securing Cloud APIs, it’s critical to implement a series of best practices to protect against unauthorized access and ensure data integrity. Here's a list of API security best practices for securing your cloud APIs:

Authentication and Authorization

Use Strong Authentication: Implement strong, multifactor authentication mechanisms to verify the identity of users and services.
Leverage OAuth 2.0: Utilize OAuth 2.0 protocol for delegated authorization, providing tokens instead of sharing credentials.
Employ Role-Based Access Control (RBAC): Define roles and privileges to limit access to API functionalities based on user roles.
API Keys: Use API keys for simpler scenarios with caution, ensuring they are not exposed in client-side code.

Encryption and Data Protection

Enforce TLS: Use Transport Layer Security (TLS) to encrypt data in transit between the client and your API.
Sensitive Data: Avoid transmitting sensitive data unless necessary, and if you must, use additional end-to-end encryption.
Data at Rest Security: Protect data at rest through encryption and secure key management practices.

Traffic Management

Rate Limiting: Implement rate limiting to prevent abuse and mitigate DDoS attacks.
Throttling: Use throttling to control the amount of incoming traffic, ensuring equitable resource utilization and prioritizing legitimate users.
Quotas: Enforce quotas to limit the number of requests a user can make within a specified timeframe.

Monitoring and Logging

Audit Logs: Ensure detailed logging for all API access and transactions for future audits and anomaly detection.
Monitoring and Alerting: Use real-time monitoring tools to track API usage and performance, with automated alerts for suspicious activities.
Anomaly Detection: Implement systems for detecting and responding to abnormal API usage patterns that may indicate a breach.

API Gateway and Management

API Gateway: Use an API gateway to manage API requests, enforce policies, and provide an additional layer of security.
Microservices Security: When using microservices architecture, secure each individual service and API accordingly.
Version Management: Properly manage API versions to phase out older, potentially less secure endpoints.

Patching and Maintenance

Regular Updates: Keep all your API components and dependencies up to date with the latest security patches.
Vulnerability Scanning: Perform regular vulnerability scans to identify and remediate security weaknesses.
Dependency Management: Track and manage third-party libraries and dependencies, ensuring they are secure and kept up-to-date.

Input Validation and Output Encoding

Strong Input Validation: Reject any API requests with unexpected or dangerous input to prevent injection attacks.
Output Encoding: Encode data sent via APIs to prevent cross-site scripting (XSS) and other injection attacks.

Error Handling

Standardize Error Responses: Use generic error messages to prevent attackers from inferring excessive details about the backend system.
Exception Management: Properly handle exceptions to prevent leakage of stack traces or other sensitive information.

Documentation and Education

API Documentation: Provide clear documentation for the API, outlining secure usage best practices for consumers.
Developer Training: Educate developers on secure coding practices and security considerations specifically related to API development.

Compliance and Legal Aspects

Regulatory Compliance: Ensure your API meets all relevant regulatory compliance standards, like GDPR, HIPAA, or PCI-DSS.
Data Protection Laws: Understand and adhere to the data protection laws applicable to the geographical locations where your service operates.

Implementing these best practices is essential to securing Cloud APIs. Regularly reviewing and updating security measures is critical in adapting to new threats and maintaining strong API security.

Remember that there are many standards and solutions that have evolved in the cloud environment. Cloud security frameworks and standards, such as the Cloud Security Alliance (CSA) and the Open Web Application Security Project (OWASP), can help ensure cloud API security using time-tested approaches to protect sensitive information and data.

Choosing the Right API Security Solution

It is vital that you choose the right API security solution. Once you have data exposed, the cat is out of the bag, so it's important to get this right the first time. API security solutions encompass API gateways, security proxies, and cloud-based services. A thorough evaluation of their features and capabilities as a unified system aids in selecting an optimal solution tailored to your APIs, environment, and requirements.

No one solution is inherently secure, so considering your security as a complete offering - while considering the scalability, performance, and cost of API security solutions - can help ensure that you choose a solution that meets your needs and budget.

Compliance Considerations for Cloud APIs

Cloud APIs pose unique challenges in regulatory and compliance frameworks. Although they function similarly to regular APIs, their decentralized and distributed processing complicates compliance issues. This is particularly relevant under the General Data Protection Regulation (GDPR), where cloud services might use resources both within and outside GDPR jurisdictions, serving global users.

Much of this complexity arises from the difficulty in precisely auditing where data is stored and in what form. Compliance with industry standards, such as HIPAA for healthcare or PCI-DSS for payment processing, requires maintaining an audit trail for resources. However, this becomes particularly challenging in cloud environments where resources are dynamically activated and deactivated based on demand.

In cloud contexts, maintaining observability and auditability is even more critical. Strong authentication protocols such as OAuth and SAML contribute to this, mainly by facilitating access auditing. However, auditing data storage requires robust logging and monitoring systems at the data level to ensure security.

Federated services can do a lot of the heavy lifting here, allowing for ample tracking with authenticated systems that are federated and delegated, allowing for a centralization of information and a decentralization of operation.

How StackHawk Can Help with Cloud API Security

Infrastructure is only one piece of the puzzle when it comes to deploying APIs in the cloud. At the code level, ensuring that applications are secure is also crucial. StackHawk's modern dynamic API security testing (DAST) platform allows developers to test locally or in CI/CD, allowing them to detect and remedy potential security issues lurking within their applications.

Testing before the code can hit production servers running on the cloud is an essential first step in cloud API security. Experience StackHawk firsthand by signing up for a 14-day free trial today.

Top API Security Attacks: Understanding and Mitigating the Risks

StackHawk

APIs (Application Programming Interfaces) enable different applications to engage in effective data exchange, forming the backbone of countless web services, mobile apps, and internal enterprise systems. With this increased reliance on APIs, however, comes a heightened risk of security breaches. Like other software components, APIs are vulnerable to attacks that can expose sensitive data, disrupt operations, and harm an organization’s reputation. Understanding these risks and taking proactive measures to mitigate them is crucial for any business relying on APIs.

This blog will explain API security, highlight common attack vectors, and provide best practices for protecting your APIs and reducing vulnerabilities that attackers could exploit. We’ll look at how API attacks work, the potential fallout from breaches, and the steps you can take to bolster your API security posture. Regardless of your experience level with APIs, this blog aims to provide valuable insights into the critical world of API security.

What Are API Security Risks?

API security risks include vulnerabilities or weaknesses within an API that malicious actors could exploit. These risks can stem from many factors, including design flaws, implementation errors, misconfigurations, or a lack of proper security measures. If not adequately protected, this data becomes a prime target for attackers.

A successful API attack can result in data breaches, unauthorized access, service disruptions, or financial losses. The potential consequences of API security breaches are significant, making it critical for organizations to prioritize API security and proactively address potential risks. Understanding these risks is crucial for developing a robust API security strategy. By identifying and addressing potential vulnerabilities, you can proactively protect your APIs and the valuable assets they manage.

Common API Security Risks

APIs are increasingly becoming prime targets for cyberattacks due to their critical role in modern applications. As APIs grow in functionality and usage, they introduce a range of security risks that malicious actors can exploit. Understanding these risks is essential for protecting your systems and data. Below are some of the most common API security vulnerabilities that organizations must address:

Injection Attacks

Injection attacks exploit how APIs handle user input. These attacks occur when an attacker injects malicious code or commands that the API mistakenly executes. In a SQL injection attack, an attacker can alter a database query to access or manipulate unauthorized data. These attacks can bypass authentication, compromise databases, and potentially take control of the API server.

Preventing injection attacks requires validating and sanitizing inputs, using parameterized queries, and applying the principle of least privilege for database access.

Broken Authentication and Authorization

Weak authentication and authorization mechanisms, such as simple passwords, lack of multi-factor authentication, or insecure session management, can allow attackers to impersonate users, gain unauthorized access, or escalate privileges. If an API doesn’t validate session tokens properly, an attacker could hijack a session. Access control is absolutely vital to prevent unauthorized parties and threat actors from circumventing your security policies.

Mitigation strategies include enforcing strong passwords, implementing multi-factor authentication, securely managing sessions, and applying the principle of least privilege to limit access.

Excessive Data Exposure

Excessive data exposure occurs when APIs return more data than necessary, often due to insufficient filtering of responses. This can provide attackers access to sensitive information, such as user credentials, personally identifiable information (PII), or confidential business data. An API might return full user profiles, including sensitive details, when only basic information is required.

To mitigate this risk, it's important to limit the data returned by APIs to what is strictly necessary, enforce proper data filtering, and conduct regular audits to ensure no unnecessary data is exposed.

Lack of Resources and Rate Limiting

Without proper resource and rate limiting, APIs may become overwhelmed by an excessive number of requests. This can lead to performance issues or even denial-of-service (DoS) attacks. Attackers can exploit this by sending a deluge of requests to exhaust server resources, thus rendering the API unresponsive to legitimate users.

An API without rate limiting might face numerous requests per second, leading to slowdowns or crashes. Distributed denial-of-service (DDoS) attacks utilize distributed bot traffic; as the attacker floods your system with a mix of bots and zombie devices, they can limit your ability to operate in the market and generate significant costs, potentially driving a small service provider to bankruptcy.

To prevent this, implement rate limiting to control the number of requests a client can make in a given period, and allocate resources appropriately to handle unexpected spikes in traffic.

Security Misconfiguration

Security misconfiguration occurs when APIs are deployed with insecure settings, such as using default credentials, exposing unnecessary endpoints, or failing to apply security patches. These misconfigurations create easy entry points for attackers. An API with default admin credentials can be easily accessed by an attacker, allowing them to take control of the system.

To prevent security misconfiguration, it is crucial to regularly audit API configurations, remove or disable unnecessary features, apply security patches promptly, and replace default credentials with strong, unique ones.

Understanding these common API security risks is crucial for developing effective mitigation strategies and protecting your APIs from threats. By staying informed about the latest attack vectors and implementing robust security measures, you can significantly reduce your API attack surface and safeguard your valuable data.

How API Attacks Can Gain Unauthorized Access

API attacks can use various tactics to gain unauthorized access to sensitive data or systems. Understanding these methods is crucial for implementing effective security mechanisms.

Let's explore some common strategies employed by attackers:

Exploiting Vulnerabilities

Attackers frequently scan APIs for known vulnerabilities, such as injection flaws, broken authentication, or excessive data exposure. Upon discovering a weakness, they create malicious API requests to exploit it, gaining unauthorized access to data or system functions. Regular security testing and prompt patching are critical to minimizing these risks.

Brute-Forcing Credentials

In brute-force attacks, attackers systematically attempt different combinations of usernames and passwords until they find valid credentials. These attacks often target APIs with weak or no rate-limiting controls, making them vulnerable to such guessing attempts. Implementing account lockout mechanisms, enforcing strong password policies, and enabling multi-factor authentication can help defend against brute-force attacks.

Man-in-the-Middle Attacks

Man-in-the-middle (MITM) attacks occur when an attacker intercepts communication between the API and the client, allowing them to eavesdrop on or alter the transmitted data. This can lead to unauthorized access to sensitive information or manipulation of requests to an API endpoint. To prevent MITM attacks, it is essential to use strong encryption (e.g., TLS) for all data in transit and to authenticate both the client and the server.

Social Engineering

Social engineering attacks exploit human behavior to gain unauthorized access to APIs. Techniques like phishing or pretexting deceive users into revealing their credentials or providing access to the attacker. An attacker might send a fake email that appears to be from a trusted source, prompting the user to log in to a malicious site. Educating users about social engineering tactics and implementing robust authentication methods can mitigate these risks.

By employing these tactics, attackers can bypass security measures, gain access to APIs, and potentially compromise sensitive data or disrupt operations. Organizations must implement robust security measures, such as strong authentication, input validation, and encryption, to protect their APIs from potential breaches.

The Consequences of API Security Breaches

API security breaches can lead to the exposure or theft of sensitive data, like customer information, financial records, or intellectual property. The result can be significant financial losses, legal liabilities, and damage to an organization’s reputation.

The financial impact of these breaches extends beyond data loss. Organizations may face costs related to incident response, forensic investigations, legal fees, customer notifications, and potential regulatory fines. Additionally, API attacks can disrupt critical business operations, leading to service outages, downtime, and lost productivity. This can negatively affect revenue, customer satisfaction, and overall business performance.

A security breach can also severely tarnish an organization's reputation, eroding customer trust and loyalty, and making recovery a long and challenging process. Organizations may face legal action or regulatory penalties if they fail to adequately protect sensitive data, especially under regulations like GDPR or CCPA. The potential consequences of API security breaches highlight the critical need for proactive security measures.

Mitigating API Security Risks

Organizations can mitigate API security risks by adopting several key strategies. First, implement strong authentication and authorization mechanisms, such as multi-factor authentication (MFA) and OAuth 2.0, to verify user identities and enforce role-based access controls. Input validation and sanitization are crucial for preventing injection attacks; techniques like parameterized queries can help secure APIs from SQL injection vulnerabilities.

Encrypting data at rest and in transit is essential for protecting sensitive information from unauthorized access. Strong encryption algorithms and secure key management practices should be standard. Rate limiting and throttling are necessary to prevent denial-of-service (DoS) attacks by controlling the volume of requests to your API endpoints. Regular security testing, including penetration tests and vulnerability scans, is vital for identifying and fixing potential weaknesses before they are exploited.

Monitoring and logging, supported by security information and event management (SIEM) tools, are critical for detecting and responding to suspicious activity in real time. Lastly, fostering a culture of security awareness through training ensures that developers and stakeholders understand and apply API security best practices.

Implementing these strategies can reduce an organization's API attack surface and strengthen their overall security posture.

Best Practices for API Security

The threats facing APIs are constantly evolving, and staying one step ahead is crucial. Adopting industry-recognized best practices and implementing robust security measures can make your API a much harder target for attackers. Here are some best practices to help you stay ahead of the curve.

Strong Authentication and Authorization: Implement stringent access controls to ensure only authorized entities can interact with your API. Use proven security mechanisms such as OAuth 2.0, JSON Web Tokens (JWTs), or API keys for authentication. Leverage fine-grained authorization to restrict access at the resource level, granting users only the necessary permissions.
Input Validation and Sanitization: Treat all user input as potentially malicious. Implement comprehensive validation and sanitization procedures to prevent injection attacks, including SQL injection, Cross-Site Scripting (XSS), and command injection.
Secure Error Handling: Exercise caution when generating error messages. Ensure they are generic and do not inadvertently disclose sensitive information about your system or its configuration.
Encryption: Protect data confidentiality by employing encryption both when it is stored (at rest) and when it is being transmitted (in transit). Use HTTPS (TLS) for all API communications, and consider encrypting sensitive data at the database level.
Rate Limiting and Throttling: Implement rate limiting and throttling to protect against denial-of-service (DoS) attacks. These mechanisms restrict the number of requests a client can make within a specified timeframe, mitigating the potential impact of such attacks.
Regular Security Audits and Penetration Testing: Conduct periodic security audits and penetration testing to identify and address vulnerabilities in your API proactively. This practice helps ensure that your API remains resilient against evolving threats.
Security by Design: Integrate security into every stage of the API development process. Treat security as a fundamental requirement rather than an afterthought. Consider following established frameworks like the OWASP API Security Top 10.
Continuous Updates and Patching: Keep your API, its dependencies, and your infrastructure patched and up-to-date. New vulnerabilities are discovered regularly, so staying up-to-date is vital for mitigating risks.

API security is an ongoing process, by following these best practices and remaining vigilant, you can significantly reduce the risk of API attacks and protect your valuable data.

The Importance of API Security Testing

API security testing is a critical component of any organization’s cybersecurity strategy. As APIs become more integral to application functionality, they also become prime targets for cyberattacks. Vulnerabilities within APIs can expose sensitive data, disrupt operations, and lead to significant financial and reputational damage.

Security testing of APIs is essential to protect these critical interfaces from potential threats. Without thorough testing, APIs may have flaws that malicious actors can exploit to gain unauthorized access or disrupt services. These risks are not theoretical; breaches involving APIs are becoming increasingly common as attackers recognize the potential for substantial impact.

In addition to preventing breaches, API security testing helps organizations comply with industry regulations and standards that mandate the protection of sensitive data. It also fosters a culture of proactive security, where potential issues are identified and addressed before they can be exploited.

Investing in thorough API security testing is essential for any organization. By prioritizing API security, organizations can protect their operations, maintain customer trust, and secure the long-term success of their applications in the face of continually evolving threats.

Improving API Security with StackHawk

StackHawk offers a solution for improving API security, enabling developers to efficiently identify and address vulnerabilities. Seamlessly integrating into development workflows, StackHawk automates security testing and provides real-time feedback without compromising productivity.

StackHawk allows thorough testing for a wide range of API vulnerabilities, including those outlined in the OWASP API Security Top 10, ensuring rigorous examination of critical security risks. Its developer-friendly tools deliver clear, actionable feedback, allowing developers to resolve security issues quickly and effectively.

StackHawk's automation capabilities integrate smoothly into CI/CD pipelines, facilitating early vulnerability detection and making security checks an integral part of the development cycle. With fast, efficient scans, StackHawk minimizes disruption to development while prioritizing security.

By integrating StackHawk into their API security strategy, organizations can enhance their ability to detect and address vulnerabilities, ensuring their APIs remain robust and resilient against evolving threats.

API Security Trends and Threats

As API threats continue to evolve, it's essential for API security measures to advance in tandem. Staying informed about emerging trends and threats is crucial for maintaining a strong defense. As APIs become more prevalent and complex, the attack surface expands, increasing the opportunities for exploitation.

Attackers are developing increasingly sophisticated techniques specifically targeting APIs. They exploit business logic flaws and misuse API functionalities to gain unauthorized access or disrupt services. In response, organizations are adopting a "shift-left" approach, integrating security earlier in the development process to identify and address vulnerabilities before they reach production.

Both attackers and defenders are leveraging artificial intelligence and machine learning: attackers to automate and enhance their methods, and defenders to improve threat detection and response. Accordingly, you must have a holistic view of the security environment to effectively prevent API security incidents.

Keeping up with these trends and threats enables organizations to proactively adjust their security strategies, ensuring that APIs remain resilient against the evolving threat landscape.

Conclusion

APIs are essential for modern software, yet their widespread use exposes organizations to significant security risks. The severe consequences of API security incidents, including data loss, financial damage, and reputational harm, underscore the importance of robust API security. Understanding common threats, adopting best practices, and proactively mitigating risks are paramount. Robust authentication, input validation, encryption, and regular security testing are vital components of a comprehensive API security strategy.

API security is a continuous process. To safeguard your assets and ensure the success of your digital initiatives, it is crucial to stay informed, adapt to evolving threats, and consistently prioritize security. To learn more about StackHawk’s approach to API Security, visit StackHawk.com, and sign up for a free trial.

5 Common Causes of API Security Breaches and How to Prevent Them

Matt Tanner

APIs play a fundamental role in modern software development by allowing different applications to communicate and work together. Yet, as the complexity and significance of APIs have increased, they've become attractive targets for attackers seeking to find and exploit weaknesses to access confidential information without permission.

In this blog, we'll cover the common causes of API security breaches and explore some effective methods to boost your security. By understanding the risks and taking proactive measures, you can safeguard your APIs and protect your valuable assets from cyber threats.

Understanding API Security

An API, or Application Programming Interface, allows different software systems to communicate and share information. They are essential for everything from basic web applications to intricate enterprise systems. Unfortunately, this essential connectivity that APIs provide also makes them vulnerable to attacks if they are not adequately secured.

API security involves a range of practices and technologies designed to protect these interfaces from unauthorized access, data breaches, API security breaches, and other malicious activities.

The Growing Threat of API Attacks

API attacks are on the rise, with an increasing number of organizations experiencing an API security incident. A successful API hack can expose Personally Identifiable Information (PII) and negatively impact trust between organizations and users.

Cybercriminals are continually refining their strategies, making APIs an increasingly appealing target because of the sensitive data they frequently manage. A successful API attack can lead to data breaches, financial losses, and reputational damage, making API security a top priority for organizations of all sizes.

Several factors contribute to the increasing threat of API attacks. The increase in API usage, their frequent exposure to public access, and the complexity of modern API architectures contribute to an environment full of potential vulnerabilities. The rise of automation and AI-powered attack tools makes it easier for attackers to scan for and exploit weaknesses at scale, and this constantly evolving threat landscape can create a sort of arms race between security vendors and malicious actors.

Common Causes of API Breaches

APIs are essential connectors for modern applications, but their accessibility and power can make them attractive and vulnerable targets. Let’s explore some common security risks that lead to breaches.

Insecure API Design

A secure API begins with a robust design. Neglecting security at the outset introduces vulnerabilities, making the API susceptible to exploitation. APIs should adhere to the principle of least privilege, revealing only the minimum necessary data. Overly permissive APIs can inadvertently leak sensitive information and lead to an API security breach.

Strong authentication and proper authorization mechanisms are key access controls. Without them, unauthorized parties can easily gain entry and exploit the system. Handling these components involves not just operating the system but also securing it. For example, poor management of API keys can cause major security breaches and financial losses. Hackers can take advantage of these weak points to access sensitive systems without permission, potentially leading to more severe and harmful API security incidents.

Rigorous input validation and sanitization are necessary to prevent injection attacks and malicious code execution. Addressing these design flaws early in the development process significantly strengthens API security. Security should be a foundational design principle, not an afterthought.

Insufficient Security Measures

Even a well-designed API can be compromised without adequate security measures. Common vulnerabilities include weak authentication, where easily guessable passwords or basic methods offer insufficient protection. Implementing strong password policies and multi-factor authentication can enhance security significantly.

Inadequate encryption is another critical issue. Failure to encrypt data, either in transit or at rest, exposes it to unauthorized access. Robust encryption protocols are essential for protecting sensitive information. Insufficient logging and monitoring can allow malicious activity to go undetected. Comprehensive logging and real-time monitoring are necessary for the timely identification and response to threats.

Addressing these security gaps is essential for securing APIs and requires both sound design and the implementation of effective security measures to protect against various threats and maintain the integrity and confidentiality of digital services.

Misconfigured and Outdated APIs

APIs demand continuous maintenance and attention. Misconfigurations and outdated software introduce exploitable vulnerabilities, undermining even the strongest security measures. Misconfigurations, such as incorrect security settings or exposed endpoints, create weaknesses attackers can exploit.

Regular configuration reviews and audits help identify and resolve these issues. Outdated software leaves APIs susceptible to known exploits. Attackers actively target systems running outdated software, making regular updates essential for staying ahead of threats.

Proactively addressing misconfigurations and ensuring APIs are up-to-date is crucial for mitigating risks and safeguarding your data. API security requires sound design, robust measures, ongoing maintenance, and vigilance.

Preventing API Security Breaches

Let’s look at some proactive strategies that will help you safeguard your APIs against potential threats and generate a strong security posture. Implementing a multi-layered defense, encompassing secure design principles, robust security measures, and continuous testing and governance, will significantly reduce your API’s vulnerability to attacks.

Secure API Design and Development

Building security into your APIs from the beginning is crucial. Adhering to the principle of least privilege minimizes potential damage by granting users only the permissions they need. Robust input validation and sanitization act as gatekeepers, filtering out malicious data before it can wreak havoc.

Comprehensive error handling and logging provide invaluable insights into potential security incidents, aiding in swift identification and response. Following secure coding practices throughout the development process is fundamental in preventing vulnerabilities from being introduced into your codebase.

API Security Governance and Testing

Maintaining robust API security demands continuous attention and a proactive approach. Regular security testing, including penetration tests and vulnerability scans, serves as your frontline defense, uncovering potential weaknesses before attackers can exploit them.

Complementing periodic security audits ensure your APIs adhere to established policies and industry best practices, minimizing the risk of oversight. Continuous monitoring and logging act as your API's early warning system, detecting suspicious activity in real-time so you can respond swiftly.

Should an incident occur, a well-defined incident response plan ensures a coordinated and effective response, minimizing damage and downtime.

How StackHawk Works: Your API Security Partner

StackHawk is an API security testing platform designed to help developers identify and remediate vulnerabilities early in development. By integrating with your existing development workflow, StackHawk enables you to continuously test your APIs for security issues, ensuring that vulnerabilities are identified and addressed before they can be exploited.

Automate API Discovery and Security Testing

Deploy StackHawk's API Discovery capabilities to keep a precise inventory of every API within your attack surface. With every API identified, integrate StackHawk into your CI/CD pipeline to trigger automated security scans with every code change, providing comprehensive coverage of your API endpoints and identifying vulnerabilities such as injection flaws, broken authentication, and sensitive data exposure.

Identify and Prioritize Risks

Generate detailed security reports with clear, actionable insights, including vulnerability severity levels, exploitability, and remediation guidance, allowing you to focus on the most critical risks and allocate resources effectively.

Shift Left on Security

Empower developers to proactively address security issues by providing real-time feedback and vulnerability alerts, promoting a security-first mindset, and reducing the cost and complexity of fixing vulnerabilities later in the development cycle.

StackHawk Secures APIs

By incorporating StackHawk into your development process, you can proactively protect your APIs from attacks, reduce the risk of breaches, and ensure your valuable data's confidentiality, integrity, and availability.

Conclusion

As APIs become increasingly central to modern software development, they also become attractive targets for cybercriminals. By understanding the common causes of API breaches and implementing robust security measures, you can safeguard your APIs and protect your valuable assets from unauthorized access and data breaches.

API security is an ongoing process that requires continuous vigilance, regular testing, and a proactive approach to identifying and addressing vulnerabilities. By incorporating security into every stage of the API development lifecycle and leveraging tools like StackHawk, you can build and maintain secure APIs that enable innovation while protecting your data and users. Sign up today for a 14-day free trial.

Understanding and Protecting Against API7: Server-Side Request Forgery

Matt Tanner

Server-Side Request Forgery (SSRF) is a critical web application vulnerability that often flies under the radar. It allows attackers to misuse your application’s functionality to access resources they shouldn’t, potentially leading to data leaks, unauthorized system access, and even remote code execution. A Web Application Firewall is essential in preventing SSRF attacks as part of a broader application security strategy.

We'll break down the intricacies of SSRF, covering its various forms, the ways attackers exploit it, and most importantly, the strategies you can employ to protect your applications. Whether you’re a developer, security professional, or simply interested in web security, understanding SSRF is crucial for keeping your systems safe.

What is SSRF?

SSRF is a vulnerability where attackers manipulate your application into making requests it wasn’t designed to make. This often involves exploiting features that fetch data from external sources. By selecting a target URL, attackers can manipulate URLs to access or modify restricted resources, tricking your application into sending requests to internal systems, external services, or back to your server.

How it Works

Imagine your application has a function to retrieve product images from a user-supplied URL. An attacker could modify this URL path to point to a sensitive internal server, potentially leaking confidential company information.

Attackers can target internal servers to exploit the lower traffic and carry out malicious actions such as port scanning, accessing sensitive data, and compromising internal services. In another scenario, they might try to access a service running on a different port on your server, which could reveal vulnerabilities or even allow for remote code execution.

Impact of SSRF Attacks

A successful Server-Side Request Forgery (SSRF) attack can have devastating consequences, from exposing sensitive data and granting unauthorized access to internal systems, to enabling full system compromise through remote code execution:

Data Leaks: SSRF can expose sensitive information, such as user data, authentication credentials, or internal system details. This can lead to identity theft, fraud, and other malicious activities.
Unauthorized Access: Attackers can use SSRF to bypass firewalls and access internal systems that are not exposed to the public internet. This can give them a foothold within your network and allow them to launch further attacks. Additionally, attackers can exploit SSRF vulnerabilities to gather sensitive data from internal networks, mapping them and compromising services.
Remote Code Execution (RCE): In the worst-case scenario, SSRF can be exploited to execute arbitrary code on the server, this gives the attacker complete control over the application and its underlying infrastructure, allowing them to steal data, install malware, or even take down the entire system.

The impact of an SSRF attack goes beyond technical issues. It can result in financial losses due to downtime, legal liabilities due to data breaches, and damage to your organization’s reputation. Therefore, it’s crucial to take proactive measures to prevent and mitigate SSRF risks.

Types of SSRF Attacks

Server-Side Request Forgery (SSRF) isn't a single, uniform vulnerability. It comes in various forms, each with unique risks and requiring specific defenses to safeguard your application.

Basic SSRF: This is the simplest form, where an attacker directly manipulates a URL to access internal resources or external services. For example, they might change a URL in your application to point to a sensitive internal server.
Blind SSRF: In this case, the attacker doesn’t receive a direct response from the server, making it harder to detect. However, they can still infer the success of their attack by observing side effects, such as delays in the application’s response or changes in the server’s logs.
SSRF with Authentication Bypass: Some applications have authentication mechanisms to protect internal resources. However, if these mechanisms are not properly implemented, an attacker can bypass them using SSRF. This can give them access to sensitive data or functionality that they shouldn’t have.
SSRF to Local File Inclusion: This type of attack involves manipulating a request to read or include local files from the server’s file system. Attackers could gain access to configuration files, source code, or other sensitive information.
SSRF to Port Scanning: Attackers can leverage SSRF to scan ports on internal systems, potentially discovering open services or vulnerabilities that can be exploited.

Understanding these different types of SSRF attacks is crucial for developing effective mitigation strategies. By recognizing the specific threats, you can tailor your defenses to protect your applications.

SSRF Attack Vectors

Server-side request forgery vulnerabilities can be exploited through various attack vectors, depending on the application’s design and functionality:

Image Processing Libraries: Applications that process images from user-provided URLs are particularly vulnerable. Attackers can craft URLs that point to internal resources or external services, potentially triggering SSRF attacks. They can manipulate URL paths to exploit vulnerabilities in server functionality, targeting applications that import or read data from URLs.
File Upload Functionality: If an application allows users to upload files and the server fetches or processes them from a URL, it can be exploited for SSRF. Attackers can upload a file containing a malicious URL that the application will later access.
Web Proxies and Caching Systems: If an application uses a web proxy or caching system, attackers can manipulate the URLs used by these systems to trigger SSRF attacks. They might inject a malicious URL into the cache which will then be fetched by other users.
APIs and Third-Party Integrations: APIs and third-party integrations often involve fetching data from external sources, making them potential targets for SSRF. Attackers can manipulate the API requests or integration parameters to trigger SSRF attacks.
URL Redirection: If an application allows URL redirection based on user input, attackers can exploit this to redirect requests to internal resources or external services.
Input Validation Flaws: Applications that don’t properly validate or sanitize user input are vulnerable to SSRF. Attackers can inject malicious URLs or payloads into input fields, leading to SSRF attacks.

Understanding these common attack vectors is essential for identifying and mitigating SSRF risks. You can significantly reduce your application’s vulnerability to SSRF attacks by securing these potential entry points.

How to Prevent SSRF Attacks

Preventing SSRF attacks requires a multi-layered approach that combines secure coding practices, network configuration, and input validation:

Input Validation: The most fundamental defense is to validate and sanitize any user-supplied input that could be used to construct URLs or network requests. This involves implementing a whitelist of trusted domains and IP addresses, parsing and normalizing URLs, and sanitizing input to remove or escape potentially harmful characters. While blacklisting known malicious sources can be helpful, it's less effective than whitelisting due to the constantly evolving nature of threats.
Network Segmentation: Isolate internal systems and services from the public internet whenever possible. This reduces the attack surface and makes it harder for attackers to reach sensitive resources even if an SSRF vulnerability is exploited.
Disable Unnecessary Protocols: If your application doesn’t require certain protocols like file://, gopher://, or dict://, disable them to prevent attackers from using them in SSRF attacks.
Least Privilege Principle: Follow the principle of least privilege by granting your application only the minimum necessary permissions to access external resources.
Web Application Firewalls (WAFs): Deploy a WAF to monitor and filter traffic to your application. WAFs can detect and block suspicious patterns in requests, including those that might indicate an SSRF attack.
Regular Security Testing: Perform regular security assessments, including penetration testing and code reviews, to identify and address SSRF vulnerabilities before attackers can exploit them.

By implementing these preventive measures, you can significantly reduce the risk of SSRF attacks and protect your applications and their underlying infrastructure.

Example Attack Scenario

To illustrate the potential impact of a Server-Side Request Forgery (SSRF) attack, let's examine a hypothetical scenario involving a seemingly benign feature on an e-commerce platform.

The Vulnerable Application

An e-commerce platform uses a third-party service to generate product images based on user-provided parameters. The application sends these parameters to the service via an HTTP request, and the service returns the generated image.

The Attack

An attacker discovers that they can manipulate the parameters in the request to include a URL pointing to an internal server. This server hosts sensitive data, such as customer credit card information and order details.

The Exploit

The attacker crafts a malicious request that includes the URL of the internal server. The application sends the request to the third-party service, which then fetches the remote resource from the internal server and returns it to the attacker.

This demonstrates how a seemingly harmless feature, like image generation, can be exploited for malicious purposes if not properly secured against SSRF attacks. It highlights the importance of understanding the potential attack vectors and implementing robust preventive measures to protect your applications and their users.

How StackHawk Can Help Detect and Prevent SSRF

When it comes to traditional DAST solutions, SSRF detection was usually not an option. Luckily, StackHawk goes beyond traditional DAST solutions by actively testing for SSRF (Server-Side Request Forgery)

StackHawk is a modern, powerful DAST tool designed for developers to integrate application security testing seamlessly into their software development lifecycle. It is not just another security tool; it's a developer-first platform emphasizing automation, ease of use, and integration into existing development workflows.

At its core, StackHawk is built around empowering developers to take the lead in application security. It provides a suite of tools that make it easy to find, understand, and fix security vulnerabilities before they make it to production. One of the critical components of StackHawk is HawkScan, a dynamic application security testing (DAST) tool that scans running applications and APIs to identify security vulnerabilities.

With StackHawk, developers and security teams can:

Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.

By focusing on a developer-first approach to security testing and integrating smoothly into existing dev tools and practices, StackHawk demystifies application security, making it a more approachable and manageable part of the software development lifecycle. Next, we will look at exactly how simple it is to configure StackHawk to begin testing your applications for potential SSRF vulnerabilities.

Enabling SSRF Detection in HawkScan

Enabling SSRF detection in StackHawk is easy. Once you have StackHawk up and running, you can go to the Applications screen and click on the Settings link for your application.

Next, on the Settings screen, under HawkScan Settings, click the Applied Policy dropdown and select the "Production-Safe" policy.

Next, click the Customize Policy button right beside the dropdown.

On the next screen, under the Plugins and Tests section, click on the SSRF entry to enable HawkScan to execute tests for potential SSRF vulnerabilities.

When you run your tests with StackHawk, they will include testing for potential SSRF vulnerabilities!

Conclusion

Understanding SSRF is a crucial first step in securing your web applications, but implementing robust input validation and sanitization mechanisms in the real world can be complex. The key lies in empowering your developers with the tools and knowledge they need to build security into the core of your application design.

StackHawk goes beyond simply identifying potential SSRF vulnerabilities in your running application. It bridges the gap between detection and remediation by providing clear explanations, actionable guidance, and seamless integration into your existing development workflows. This collaborative approach makes web application security less intimidating and helps developers instill secure coding practices.

By proactively using StackHawk to detect and address SSRF vulnerabilities, you can significantly minimize the risks of this common API threat. Sign up for a 14-day free trial of StackHawk today to experience the difference StackHawk makes in detecting SSRF vulnerabilities and other API security issues outlined in the OWASP API Top 10.

Web API Security: Essential Strategies and Best Practices

StackHawk

In software development, APIs (Application Programming Interfaces) are at the core of modern applications. They enable communication and data exchange between different software components, enabling users and services to access data, leverage external services, engage in data transfer, and much more.

However, the increased reliance on APIs has made them prime targets for malicious actors. API security breaches can have devastating consequences, including data leaks, system compromise, and financial losses. Potential security threats continue to develop methods of attack, targeting providers ranging from Twitter to the US Department of State.

In this article, we’ll explore the world of web API security, exploring the essential strategies and best practices that developers and organizations can implement to safeguard their APIs and protect sensitive data.

From understanding the common API security threats to implementing robust security measures and staying ahead of emerging trends, we’ll provide you with a comprehensive guide to strengthen your API ecosystem.

Understanding API Security

APIs act as gateways to your application’s data and functionality, making them attractive targets for hackers. If not adequately secured, APIs can become entry points for unauthorized access, data breaches, and other malicious activities.

Proper API security involves implementing a multi-layered approach to protect your APIs from attacks. This includes securing the API endpoints, managing security protocols like TLS on your web server, authentication and authorization mechanisms, input validation, and encryption of sensitive data.

APIs often handle sensitive data, such as Personally Identifiable Information (PII), financial information, and intellectual property. Prioritizing API security is crucial for ensuring the confidentiality, integrity, and availability of your data. By implementing robust security measures, you can protect your users, your business, and your reputation.

API Security Threats

The threat landscape surrounding APIs continues to evolve, with attackers deploying increasingly sophisticated techniques. Understanding the most prevalent API security threats is crucial for safeguarding these vital interfaces.

From injection attacks to security misconfigurations, each threat presents unique challenges that require proactive measures. By recognizing these risks and implementing robust security practices, organizations can protect their APIs and ensure the integrity of their systems.

Injection Attacks

Injection attacks are a persistent API security threat, exploiting input validation vulnerabilities where attackers inject malicious code or commands into API requests, aiming to manipulate the system. Common examples include SQL injection, where attackers manipulate database queries, and command injection, where they attempt to execute system commands on the API server.

These attacks bypass traditional security, directly interacting with the system, often with devastating consequences. Protection requires robust input validation, sanitization, and parameterized queries or prepared statements.

Broken Authentication and Authorization

Authentication verifies a user's identity, while authorization determines their access privileges. Weak or flawed implementation of these mechanisms can lead to unauthorized access and data breaches. Attackers might exploit vulnerabilities to bypass authentication, impersonate legitimate users, or escalate their privileges, gaining access to sensitive information or critical functionalities.

Broken authentication might involve vulnerabilities in password storage, session management, or token handling, allowing attackers to bypass logins or impersonate users.

Broken authorization can manifest at both the function and object levels. Broken Function Level Authorization (BFLA) occurs when APIs fail to enforce proper access controls at specific endpoints, allowing unauthorized actions. Meanwhile, Broken Object Level Authorization (BOLA) arises when APIs lack adequate checks to restrict access to data within the system, allowing attackers to view or modify data they shouldn't have access to.

These flaws can have severe consequences, enabling privilege escalation, data access, or malicious actions. Implementing robust authentication and authorization mechanisms, role-based access control, and granular permissions, is essential to mitigate these risks.

Excessive Data Exposure

APIs might inadvertently expose more data than necessary, including sensitive information that attackers could exploit, this common threat is known as excessive data exposure. Developers must be vigilant for overly permissive access controls, improper filtering of responses, or failure to mask sensitive data.

Providers should be aware of the data managed by their APIs, as well as external data source security vulnerabilities, such as those facing third party services underpinning data processing, web servers, or other API providers used as partners to provide services. Awareness is a key component of data security, so check often and validate your understanding! Data leaks can have serious consequences, including privacy violations and compliance issues.

Lack of Resources and Rate Limiting

Without proper resource management and rate limiting, APIs become vulnerable to denial-of-service (DoS) attacks, attackers can exploit this weakness by flooding the API with excessive requests, consuming its resources, and making it unavailable to legitimate users. This disruption can impact business operations, causing downtime, financial losses, and damage to the user experience.

Implementing rate limiting and resource controls is essential to mitigate this risk, ensuring fair access to API resources and protecting against malicious attempts to overload the system.

Security Misconfigurations

Misconfigurations in API settings, such as exposing sensitive endpoints, using default credentials, or leaving debugging features enabled create exploitable vulnerabilities for attackers. These misconfigurations can arise from human error, lack of oversight, or inadequate security practices during development and deployment.

Understanding these common API security threats is essential for developers and organizations to implement proactive measures to protect their APIs. Staying informed about the latest attack techniques and vulnerabilities enables you to develop a stronger security strategy and protect your valuable data and applications.

Protecting Sensitive Data

APIs often handle sensitive information, making them a prime target for malicious actors seeking to exploit valuable data. Implementing robust security measures is critical to protect this sensitive data from unauthorized access and breaches. Here are some key strategies to consider.

Encryption

Encrypting data both at rest and in transit adds a critical layer of protection. Even if data is intercepted, it remains unreadable without the decryption keys. Utilizing strong encryption algorithms and practicing secure key management is vital to ensuring the confidentiality of your data.

Data Minimization

Collect and store only the sensitive data necessary for your API's functionality. By minimizing the amount of sensitive data handled, you reduce the potential impact of a breach. Remember, every piece of data you collect increases your attack surface.

Access Control

Implement granular access controls to restrict access to sensitive data based on user roles and permissions. Ensure that only authorized users have access to specific data sets and functionalities. Strong access control systems ensure that only authorized users can access protected resources, safeguarding sensitive data.

Tokenization

Tokenization replaces sensitive data with unique tokens that have no intrinsic value. In the event of a breach, the tokens are useless to attackers, significantly reducing the risk of exposing actual sensitive information.

Masking

Obfuscate or mask sensitive data when displaying it to users or third-party systems. This practice helps protect sensitive information from accidental exposure. For example, when displaying a credit card number only show the last four digits.

By strategically implementing these protective measures, you can reduce the risk of sensitive data exposure and ensure the privacy and security of your user's information. Safeguarding sensitive data isn't just about compliance; it's about building trust and protecting the individuals who rely on your applications.

Securing API Requests

Protecting your API endpoints from malicious requests is crucial to prevent unauthorized access and potential attacks. Implementing a combination of techniques can improve your API request handling.

Input Validation

This is the first step in protecting your API. By validating all incoming API requests to ensure they conform to expected formats and data types, you can proactively reject any requests that contain invalid or malicious input.

This prevents potentially harmful data from reaching your system and causing unintended consequences.

Sanitization

This acts as a protective filter, removing any potentially harmful characters or scripts from user input that could be used in injection attacks, thus ensuring the integrity of the API.

It's best practice to use parameterized queries or prepared statements to protect against SQL injection attacks. This approach helps separate user input from the actual SQL commands, making it more difficult for attackers to inject malicious code into your database queries.

Output encoding

This is key to prevent cross-site scripting (XSS) attacks. By properly encoding API responses, you can convert special characters into their corresponding HTML entities, rendering them harmless if they are injected into a web page. This helps prevent attackers from executing malicious scripts in the context of your application.

Rate Limiting

Finally, implementing rate limiting is critical to preventing denial-of-service (DoS) attacks and abuse of your API resources. By restricting the number of requests a user or IP address can make within a specified timeframe, you can prevent attackers from overwhelming your API with excessive requests.

By incorporating these techniques into your API security strategy, you can create a more secure environment for handling API requests, making it significantly more difficult for attackers to exploit vulnerabilities and gain unauthorized access.

API Security Testing

Regularly testing your APIs for security vulnerabilities is crucial for staying ahead of potential threats. It allows you to proactively identify and address weaknesses before malicious actors can exploit them. One approach is penetration testing, where security professionals simulate real-world attacks on your APIs.

This hands-on approach uncovers vulnerabilities and helps assess the effectiveness of your existing security measures. Another valuable technique is fuzz testing where your API endpoints are subjected to a barrage of malformed or unexpected inputs, you can uncover potential weaknesses in how your API handles unexpected data.

Static code analysis is also important, your codebase is scanned with specialized tools that can help identify security flaws and vulnerabilities early in the development process, saving time and effort later on. Finally, dynamic application security testing (DAST), using tools like StackHawk, provides real-time vulnerability scanning of your running APIs. This approach helps catch security issues that might only become apparent during runtime interactions.

Combining regular API security testing with continuous monitoring and effective vulnerability management helps you create a resilient API ecosystem, ready to face the evolving threat landscape.

Security Testing with StackHawk

StackHawk is a powerful API security testing platform designed specifically for developers. It seamlessly integrates into your development workflow, offering continuous security testing and vulnerability detection without disrupting your existing processes.

This integration helps identify and fix security risks early in the development process. Some key benefits to using StackHawk include:

Automate API Security Testing

StackHawk automates the testing and testing of your APIs, making it easy to incorporate security testing into your CI/CD pipeline. This helps identify vulnerabilities early, reducing the risk of security breaches and saving valuable development time.

Get Real-time Feedback

StackHawk provides instant feedback on identified vulnerabilities, along with detailed remediation guidance. This actionable information empowers developers to understand the nature of the vulnerability, assess its potential impact, and implement the necessary fixes promptly and effectively. By addressing security issues early, developers can maintain a high level of security throughout the development process.

Customized Testing

Tailor your API security tests to focus on specific areas of concern, such as compliance with industry standards like PCI DSS or HIPAA, or target specific vulnerabilities like the OWASP Top 10. This allows you to prioritize critical vulnerabilities and ensure your APIs meet industry standards.

Collaborate Seamlessly

StackHawk fosters collaboration between developers and security teams. It provides a centralized platform where both teams can access test results, track remediation progress, and share insights. This collaborative approach promotes shared responsibility for API security and facilitates a smooth and efficient resolution of security issues.

By incorporating StackHawk into your development process, you can proactively identify and fix API vulnerabilities, building more secure and resilient applications from the ground up.

API Security Best Practices

To ensure the robust security of your APIs, consider implementing these essential best practices:

Strong authentication and authorization

Implement authentication mechanisms like OAuth 2.0 or OpenID Connect, and implement role-based access control (RBAC) to restrict access to specific API resources based on user roles and permissions.

Input validation and sanitization

Ensure all incoming API requests are validated and sanitized to prevent injection attacks and other malicious activities.

Error handling and logging

Implement proper error handling and logging mechanisms to capture and analyze API errors and exceptions. This helps identify potential security issues and provides valuable insights for troubleshooting and incident response.

Regular security updates and patching

Keep your API frameworks, libraries, and dependencies up to date with the latest security patches and updates. This helps mitigate known vulnerabilities and protect against emerging threats.

Security awareness and training

Educate your development and operations teams on API security best practices and the latest threats. Encourage a culture of security throughout your organization.

Encrypt data in transit with TLS

Always use TLS (Transport Layer Security) to encrypt data transmitted between clients and your API. This prevents eavesdropping and tampering with sensitive information.

Implement rate limiting and throttling

Protect your API from abuse and denial-of-service attacks by limiting the number of requests a user or IP address can make within a given time frame.

Use an API gateway

API gateways can act as a central control for your APIs, providing features like authentication, authorization, rate limiting, and traffic management. This helps simplify security management and provides a unified interface for accessing and managing your web APIs.

Following these best practices and staying informed about the latest API security trends, you can build and maintain a secure API ecosystem that protects your data, users, and business.

Advanced API Security Topics

API security strategies must keep up with the increasing complexity of cyberattacks. The core security measures we've discussed provide a strong foundation, but truly robust API protection requires going beyond the basic security measures. These advanced topics address the evolving threats and architectural complexities of modern applications.

Zero Trust Security

Zero Trust Security rejects the traditional model of implicit trust within networks, adhering to the principle of "never trust, always verify." Verifying every request, regardless of origin, zero trust minimizes the potential for unauthorized access and lateral movement within your network, even after a breach.

For APIs, this means implementing strict access controls, multi-factor authentication, and granular authorization policies. It also involves continuous monitoring to identify anomalies and threats. Embracing zero trust protects your APIs against unauthorized access, ensuring every interaction is scrutinized.

API Gateway

An API gateway is a powerful intermediary, that efficiently manages all API traffic. It consolidates security controls, traffic management, and monitoring capabilities, simplifying security and streamlining API access. Functioning as a central hub, it handles authentication, authorization, rate limiting, and provides a unified interface for managing and monitoring your APIs. This simplifies security and improves overall performance and reliability.

Artificial Intelligence and Machine Learning

Artificial intelligence (AI) and machine learning (ML) are revolutionizing API security. These technologies analyze vast API traffic data, detecting subtle patterns and anomalies that signal malicious activity. They continuously learn normal behavior and flag deviations, such as unusual requests or access attempts. ML models can also recognize specific attack patterns, enabling real-time threat detection and mitigation.

DevSecOps

DevSecOps is a cultural and technical shift that integrates security practices into every stage of the DevOps process. This approach fosters collaboration between development, security, and operations teams, promoting shared responsibility for security. By embedding security testing and analysis into the CI/CD pipeline and automating security checks, DevSecOps enables faster and more secure releases.

Vulnerabilities are identified and addressed early, reducing the cost and complexity of remediation. This proactive approach ensures that security is not an afterthought but a foundational element of the development process, leading to more secure and resilient APIs.

Object Level Authorization

Fine-grained object-level authorization in your APIs ensures users access only the data or resources they are authorized to. Improper implementation can lead to Broken Object Level Authorization (BOLA) vulnerabilities, allowing attackers to bypass restrictions and access or manipulate unauthorized data.

To prevent BOLA, it's important to define and enforce clear access control policies at the object level and regularly review and update them to adapt to changing user roles and data sensitivity.

Service Meshes

Service meshes address the complexity of microservices architectures, enhancing API security and observability. They are a dedicated communication layer, offering features like traffic encryption, authentication, authorization, and monitoring.

Centralized control ensures that every API call is protected by enforcing consistent security policies across all services. Service meshes provide insights into microservices behavior, aiding performance optimization and threat detection. Adopting a service mesh enhances your API's resilience and simplifies management in a distributed environment.

By understanding and implementing these advanced API security topics, you can strengthen your API security posture, stay ahead of potential threats, and ensure the confidentiality, integrity, and availability of your valuable data and services.

Emerging Trends and Technologies

API security is constantly, evolving as new technologies emerge and attackers refine their tactics. To stay ahead of the curve and ensure your APIs remain resilient, staying up to date on the latest trends and innovations is essential.

GraphQL Security

As GraphQL adoption grows, it introduces unique security challenges due to its flexible query structure. This flexibility can be exploited through overly complex queries, leading to potential Denial of Service (DoS) attacks or unintended data exposure.

To mitigate these risks, it is essential to implement query depth limits and rigorous input validation. Proper authentication, authorization, and rate limiting are crucial to safeguard access to the API. Restricting schema introspection in production environments further minimizes the exposure of sensitive information.

Serverless API Security

The rise of serverless architectures offers scalability and flexibility but introduces unique security challenges. Serverless functions, often triggered by events, have a broad attack surface, making robust security essential. Key concerns include securing event triggers, managing authentication and authorization, and validating inputs to prevent attacks like function event-data injection.

Additionally, the use of third-party dependencies in serverless environments can introduce vulnerabilities. It's crucial to assess and secure these dependencies to avoid potential exploits. Monitoring and logging are also vital in a serverless context, where traditional security boundaries are less defined.

API Security Automation

Automation is essential in modern API security, enabling continuous protection and faster responses to vulnerabilities. By integrating automated security checks into the CI/CD pipeline, organizations can ensure that every code change undergoes rigorous testing. This approach allows for real-time detection of security issues and reduces the time needed for remediation.

Automation tools can handle repetitive tasks like vulnerability scanning, compliance checks, and threat detection, freeing security teams to focus on more complex challenges. By leveraging automation, organizations can maintain robust API security in a fast-paced development environment.

Blockchain and Decentralized APIs

Blockchain technology's inherent immutability and transparency offer promising benefits for API security. By creating tamper-proof logs of API transactions, blockchain ensures data integrity and enables auditable interactions. This approach can significantly reduce the risk of data tampering and fraud.

Decentralized APIs further enhance security by eliminating single points of failure, making systems more resilient against attacks. Because multiple nodes handle API requests, the risk of downtime or breaches is minimized, providing a more robust security framework.

AI and ML for Enhanced API Security

Artificial intelligence (AI) and machine learning (ML) are transforming API security by enabling more sophisticated threat detection and response. These technologies can analyze vast amounts of API traffic in real time, identifying subtle patterns and anomalies that might indicate potential threats. Unlike traditional rule-based methods, AI and ML can adapt to new attack vectors, providing proactive defense mechanisms.

By predicting and mitigating threats before they can cause harm, AI and ML enhance the overall security posture of APIs. Their ability to learn from past incidents and continuously improve makes them invaluable tools in safeguarding modern APIs.

Staying informed about these emerging trends and technologies allows you to proactively adjust your API security strategy and maintain a strong defense against emerging threats.

Conclusion

API security is a critical aspect of modern software development. By understanding the common threats, implementing robust security measures, and staying informed about emerging trends, you can safeguard your APIs and protect sensitive data.

As part of your development cycles, regularly test your APIs for vulnerabilities, monitor for suspicious activity, and continuously update your security practices to ensure the long-term resilience of your API ecosystem. By prioritizing API security and making it an integral part of your development lifecycle, you can build trust with your users, protect your business, and foster innovation in the digital landscape.

To get a head start on your API security, sign up for StackHawk today to quickly test and identify issues that could impact the security of your applications. Set up, test, and remedy vulnerabilities with StackHawk's modern DAST platform in minutes.

StackHawk API Discovery Webinar: Key Insights

Kaitlyn Marler

In our latest webinar “Discover your Attack Surface in 15 Minutes”, StackHawk's VP of Engineering, Dan Hopkins, Chief Security Officer, Scott Gerlach, and Solutions Architect, April Conger, unveiled StackHawk’s new API Discovery feature. The session emphasized the increasingly complex landscape of API security, highlighting the critical need for effective solutions. From the increasing volume of API production to the evolving threat landscape, organizations face unprecedented challenges in managing their APIs attack surface.

StackHawk's API Discovery feature sets itself apart by providing a comprehensive view of an organization's entire API attack surface. Unlike traditional discovery tools that rely solely on production monitoring, StackHawk's innovative approach analyzes APIs directly from the source code. This deeper level of visibility empowers organizations to identify and address security vulnerabilities proactively, rather than reactively responding to breaches.

We Took to The Polls!

Every great webinar has even better polls. Key learnings from our audience shared the need for effective API security as a must have. This session attracted a diverse audience, with 27% in AppSec, 15% in Engineering, 15% in Leadership, and 8% in DevOps roles. The different representations highlight API security as a multi-departmental challenge requiring top-down attention. When asked about their current API discovery practices, half of respondents use an automated way to monitor their API attack surface while the other half rely on manual processes to communicate the status of their API.

However, even with awareness of the issue, many organizations struggle to accurately assess their API attack surfaces. When asked, "how many APIs does your company have?", responses ranged from just a few APIs to tens of thousands, with some admitting they simply didn't know. This uncertainty is alarming, but is also a common challenge faced by many organizations. For many AppSec teams, the sheer number of APIs being produced and retired is overwhelming, making it difficult to maintain a comprehensive inventory. Others may have outdated or incomplete records, such as the use of either human knowledge or tracking within spreadsheets. These practices often lead to no visibility within an organization's attack surface.

What Keeps Teams Up at Night

When asked the question, “When thinking about your attack surface, what keeps you up at night?”, an alarming number selected "Unknown Unknowns". This uncertainty demonstrates the risks posed by undiscovered APIs. From security vulnerabilities to operational inefficiencies and compliance challenges, a lack of API visibility can have significant consequences. By proactively identifying and managing all of your organizations APIs, you can strengthen your security posture, optimize your IT operations, and mitigate compliance risks.

StackHawk's innovative API Discovery feature (offered free with enterprise plans), provides a comprehensive view of your entire API landscape. By analyzing source code rather than relying on traditional methods like expensive to run production monitoring or outdated spreadsheets, StackHawk empowers you to proactively identify and address security vulnerabilities. This proactive approach ensures the security and efficiency of your digital assets, helping you stay ahead of emerging threats.

Love for StackHawk’s API Discovery

With StackHawk, discovering your attack surface just got a whole lot easier (and faster!). We specifically asked attendees the following: “After seeing StackHawk’s API Discovery, does this change your perspective of how to discover your attack surface?” According to our poll, 60% of respondents shared that seeing StackHawk's API Discovery has changed their perspective on how to discover APIs, with many excited to try it out or share it with their team. Check out the full recording of the webinar to learn more, and deep dive into:

The evolution of web development from the past 15 years and its impact on API security
Why traditional API discovery methods fall short in modern architectures
How StackHawk's innovative approach promises to revolutionize API security management, by going straight to the source code.
A live demonstration of discovering an entire API attack surface in less than 15 minutes

Don't miss out on these valuable insights. Watch the full webinar recording or sign up to start discovering all of your APIs in just 15 minutes, for free!

The AppSec Guide to Shift-Left Security: How to Integrate Security Earlier in the SDLC

Alexa Sevilla

Unfortunately, security breaches are a harsh reality for many AppSec professionals. According to IBM’s 2023 Cost of a Data Breach Report, the average cost of a data breach has reached $4.45 million, a 15% increase over the past three years. With cyberattacks growing more sophisticated, robust security measures are no longer optional—they’re essential.

Traditionally, application security has been treated as a final step in the software development lifecycle (SDLC)—a last bastion of defense. However, as the pace of development accelerates and systems grow more complex, this approach reveals significant flaws.

The Pitfalls of Late-Stage Security

Security as a Final Step: In the traditional model, security assessments, including penetration testing and code reviews, often occur after most development work is complete. This means security is treated as an afterthought, leading to rushed fixes that don’t address root problems.
Reactive Approach: Traditional security models are inherently reactive, addressing vulnerabilities as they arise. This increases the risk of breaches and leads to inefficiencies, with teams scrambling to fix problems under tight deadlines.
Siloed Security Teams: In many organizations, security teams operate separately from development and operations teams, hindering collaboration. Without ongoing input from security experts, development teams may introduce vulnerabilities that go unnoticed until it’s too late.
Costly and Time-Consuming Remediation: Fixing security issues late in the SDLC is expensive and time-consuming. The further along in the process a vulnerability is discovered, the more resources are required to address it. This can delay product releases and increase costs, making late discovery a significant time-sink.

Real-World Consequences

The limitations of traditional security models have real-world implications. Issues such as late-stage security findings and vulnerabilities that get missed in testing with time-consuming and expensive fixes all impact your projects and, ultimately, how your customers and clients perceive you and your product:

Late-Stage Discovery: Imagine a critical vulnerability is discovered just before a product launch. The development team must drop everything to address the issue, which is causing significant delays and stress.
Missed Vulnerabilities: Certain vulnerabilities may go unnoticed without collaboration between development and security teams. For example, a development team might implement a feature without fully understanding its security implications, creating exploitable gaps.
Expensive Fixes and Reputational Damage: Vulnerabilities discovered late in the process can require extensive rework or a complete overhaul, increasing costs and potentially damaging the organization’s reputation if the issue becomes public.

These challenges underscore the need for a more integrated and proactive security approach that starts earlier in the SDLC and involves collaboration across all teams. This is where shift-left security comes in, offering a better solution for building secure applications.

Introducing Shift-Left Security

How can organizations stay ahead of security threats? The answer lies in shifting security left. This proactive strategy integrates security considerations much earlier in the SDLC, helping teams identify and mitigate risks before they escalate into costly breaches.

Shift-left security moves software security to the forefront of development. Instead of treating security as a final checkbox at the end of the SDLC, this approach embeds security practices from day one. By catching vulnerabilities early, teams can reduce the time, cost, and effort required for remediation, ultimately delivering more secure software.

Shift-Left Security: A New Paradigm

Shift-left security represents a fundamental shift in how organizations approach application security. By moving security considerations to the earliest stages of the SDLC, teams can proactively identify and address vulnerabilities before they become critical issues.

With this new paradigm, some fundamental principles must be kept in mind.

Integration of Security from the Start: Shift-left security begins by incorporating security requirements into the design phase. This ensures that security is considered a core component of the system architecture from the moment a project is conceived, not an afterthought.
Collaboration Across Teams (DevSecOps): Successful shift-left security relies on collaboration between development, security, and operations teams, often called DevSecOps. By breaking down silos, organizations can foster a culture of shared responsibility for security, ensuring it is a continuous, integrated process.
Continuous and Automated Testing: A hallmark of shift-left security is using automated security testing tools throughout the SDLC. By integrating Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Interactive Application Security Testing (IAST) into CI/CD pipelines, teams can continuously monitor for vulnerabilities as code is written, tested, and deployed, allowing for rapid identification and remediation of issues.

The Benefits of Shift-Left Security

All that being said, shift-left security, of course, happens for a multitude of reasons:

Early Vulnerability Detection: Integrating security early in the SDLC allows teams to detect vulnerabilities before they become ingrained in the codebase. Early detection reduces the time and cost of fixes and improves the application's overall security posture.
Faster Time-to-Market: Shift-left security streamlines development by resolving security issues early, reducing the need for extensive rework or last-minute fixes. This leads to more rapid and secure software delivery, helping organizations stay competitive.
Improved Collaboration and Communication: The DevSecOps approach promotes collaboration between development, security, and operations teams, ensuring security is a shared responsibility and resulting in more robust, secure applications.
Increased Customer Trust: In today's security-conscious environment, customers expect their data to be protected. By adopting shift-left security practices, organizations demonstrate their commitment to security, build customer trust, and enhance their brand reputation.

Real-World Examples of Shift-Left Security in Action

Shift-left security isn’t just about changing processes—it’s about changing the culture of how security is approached within an organization. By making small changes to how we handle security testing and processes and making them an integral part of the development process, teams can build more secure software faster, which can have a considerable impact.

Threat Modeling During Design: During the design phase of a new application, teams conduct threat modeling exercises to identify potential security risks. By understanding these risks early on, teams can design systems with security in mind, reducing the likelihood of vulnerabilities later.
Automated Security Testing in CI/CD Pipelines: Organizations that implement automated security testing as part of their CI/CD pipelines can catch vulnerabilities early and often. Continuous testing allows for quick remediation and ensures security is built into every iteration of the software.
Developer Training on Secure Coding Practices: By providing developers with training on secure coding practices, organizations empower them to write code that is resilient to attacks, preventing vulnerabilities from being introduced in the first place.
Feedback Delivered Early and Often: Integrating security teams early in the process ensures developers receive frequent and high-quality feedback, leading to better security outcomes than waiting until the end to engage the security team.

Actionable Steps for Implementing Shift-Left Security

Adopting shift-left security requires a strategic approach that integrates security practices throughout the SDLC. Here’s a step-by-step guide to get started:

1. Start with the Design Phase

The foundation of shift-left security is incorporating security considerations from the very beginning of the project. During the design phase, security requirements should be included as part of the project’s functional and non-functional specifications. This ensures that security is a key aspect of the application’s architecture. You should also conduct threat modeling exercises to identify potential vulnerabilities early. By addressing these risks in the design phase, you can build more secure systems from the outset.

2. Automate Security Testing

Automation is critical for ensuring security checks are consistently applied throughout the SDLC. Implement SAST, DAST, and IAST Tools. Static Application Security Testing (SAST) analyzes code for vulnerabilities during development, while Dynamic Application Security Testing (DAST) assesses running applications for security issues. Interactive Application Security Testing (IAST) combines both approaches, providing real-time insights as the application runs. Integrate these tools into your CI/CD pipeline to catch vulnerabilities early and ensure continuous security monitoring.

It would help if you also leveraged Continuous Integration/Continuous Deployment (CI/CD) where possible. Incorporating automated security testing into your CI/CD pipeline enforces security checks at every stage of development, ensuring vulnerabilities are identified and addressed before code is deployed to production.

3. Empower Developers

Developers play a crucial role in implementing shift-left security. Providing them with the right tools and training is essential. Offer regular training sessions to educate developers on secure coding practices and common vulnerabilities and how to avoid them. This will enhance their security awareness and equip them to write more secure code.

Another critical component is providing developer-friendly security tools. Choose security tools that integrate seamlessly into the development environment and workflows. Tools that offer actionable insights without overwhelming developers with noise are essential for encouraging adoption and fostering a security-first mindset.

4. Foster a Culture of Security

Creating a culture where security is everyone’s responsibility is vital to successful shift-left security implementation. Promote open communication between development, security, and operations teams. Regular meetings, cross-functional training, and shared goals can help break down silos and foster a collaborative environment where security is a shared priority. In agile environments, security should be part of every sprint. Incorporate security tasks into your sprint planning and retrospectives to ensure security remains a constant focus throughout development.

5. Continuously Monitor and Adapt

Security is not a one-time effort but an ongoing process that requires continuous monitoring and adaptation. By following these steps, you can effectively implement shift-left security within your organization, making security an integral part of your development process and reducing the risk of costly vulnerabilities. The security landscape constantly evolves, with new threats emerging regularly. Stay informed about the latest trends, vulnerabilities, and attack vectors to adapt your security practices accordingly. As your application evolves, so too should your security policies. Regularly review and update your security protocols to ensure they remain effective in addressing current threats.

StackHawk: Your Partner in Shift-Left Security

Implementing shift-left security can be challenging, especially for organizations new to integrating security into their development processes. This is where shift-left security tools like StackHawk come in—providing features and support to make the transition smoother and more effective.

StackHawk is a dynamic application security testing (DAST) platform designed to empower developers to take control of application security. It fits seamlessly into the shift-left approach by enabling automated security testing throughout the SDLC, ensuring that vulnerabilities are caught and addressed early in the software development lifecycle.

StackHawk fits into the shift-left paradigm in several ways:

Automated Vulnerability Testing: With StackHawk, you can automate security testing at every stage of development. This continuous testing ensures that vulnerabilities are identified and addressed early, reducing the risk of costly security issues later in the process.
Seamless CI/CD Integration: StackHawk integrates with popular CI/CD tools like Jenkins, GitHub Actions, and CircleCI, making it easy to incorporate security testing into your existing workflows. This integration allows for automatic security testing on every code commit or pull request, ensuring that security is continuously monitored.
Empowering Developers: StackHawk’s intuitive interface and detailed reports make it easier for developers to understand and fix security issues. By providing clear guidance and actionable recommendations, StackHawk empowers developers to own the security of their applications, fostering a culture of security throughout the development team.
Real-Time Feedback: With StackHawk, developers receive real-time feedback on security vulnerabilities, allowing them to address issues immediately. This reduces the time between identifying and fixing security flaws, helping teams maintain their development momentum.

By partnering with StackHawk, you can confidently shift security left, ensuring that your applications are secure from the beginning of the development process.

Conclusion

Shift-left security allows teams to detect and address vulnerabilities early by moving security to the forefront of the development process. This approach fosters collaboration through DevSecOps, leverages automated testing for continuous security checks, and empowers developers to write secure code.

A strong security posture requires collaboration across all teams—development, security, and operations. Shift-left security is not just a technical strategy; it’s a cultural shift emphasizing shared security responsibility. By breaking down silos and encouraging open communication, organizations can build a more resilient and secure software development process.

Are you beginning your journey into shift-left security? Join thousands of other AppSec and development teams that have adopted StackHawk as a cornerstone of this approach. Sign up today for a 14-day free trial, or speak with our team of security experts to get your shift-left initiatives off on the right foot.

4 Reasons Your AppSec Team Should Be Using API Discovery Tools: Unveiling the Hidden Attack Surface

Matt Tanner

APIs (Application Programming Interfaces) have become critical infrastructure for modern applications, enabling seamless integration and interaction between different systems and services. As their use has skyrocketed, so have the risks associated with them. In fact, according to recent industry reports, API-based attacks have increased by over 400% in the past year alone. One high-profile case involved a major financial institution that suffered a significant data breach due to an undiscovered and unsecured API, which exposed sensitive data for millions of customers. Incidents like this highlight the need for API discovery as part of an AppSec team's toolkit. This blog will explore API discovery and why AppSec professionals must adopt and use it.

The Need for API Discovery Tools

AppSec (Application Security) teams are under immense pressure to protect sensitive data and applications in this rapidly evolving environment. The complexity and speed of modern development often lead to gaps in security coverage, particularly in APIs. This is where API discovery tools come into play. These tools are essential for modern AppSec teams. They enable them to fully understand their API attack surface and proactively secure their applications by analyzing and testing APIs that might otherwise go unprotected in production and testing environments.

Understanding API Discovery Tools

API discovery tools are specialized solutions that automatically identify, catalog, and monitor APIs within an organization’s API footprint. By continuously scanning network traffic, code repositories, and application environments, these tools provide a comprehensive inventory of APIs, including those that might be undocumented or under-documented/protected.

This visibility is crucial in today’s complex application landscape, where the proliferation of APIs, coupled with the fast pace of development, can easily lead to security blind spots, making automatic API discovery a necessity.

Uncover and Understand Your Shadow APIs

In the rush to build and deploy new features, APIs can often be created and pushed to production without proper documentation or oversight. These undocumented APIs, known as shadow APIs, pose a significant security risk. Shadow APIs may result from rapid development, poor communication between teams, or even remnants of old versions of an application that were never fully decommissioned.

Why Are They Dangerous?

Shadow APIs are dangerous because they exist outside the typical security protocols and monitoring systems. They often lack the rigorous security measures applied to documented APIs, such as authentication, rate limiting, and input validation.

This makes them prime targets for attackers, who can exploit these unsecured/unmonitored endpoints, leading to sensitive data exposure or manipulating the application’s functionality. Since these APIs are not part of the official API documentation, they are frequently overlooked during security scans and audits, making them a hidden but significant addition to your attack surface.

How API Discovery Tools Help

API discovery tools are designed to illuminate these shadow APIs by actively scanning network traffic and code repositories to identify every API that an application uses or exposes, including those that are undocumented or unintentionally deployed.

Once identified, shadow APIs can be subject to the same security controls as the rest of the API ecosystem. AppSec teams can assess these APIs for vulnerabilities, implement necessary security measures, and integrate them into their overall security strategy. This proactive approach ensures that no API is left vulnerable to attack, no matter how obscure.

Keeping Up with the Pace of Development

Nowadays, new APIs are being created and deployed rapidly. Continuous Integration and Continuous Deployment (CI/CD) pipelines enable development teams to push code changes multiple times a day. While this speed is great for innovation and responsiveness to market demands, it also introduces significant challenges for maintaining security.

Manual tracking of these APIs is not only time-consuming but also prone to errors when done in a manner that keeps up with the speed of business. This leaves gaps that can be juicy targets for hackers. By including automated API discovery tools in the process, security teams can keep pace with the development team.

API Discovery Tools Automate the Process

To keep up with the fast pace of development, automated API discovery tools provide continuous monitoring of your API landscape. These tools integrate seamlessly into your CI/CD pipelines, ensuring that every new or modified API is automatically detected and documented. This real-time visibility allows AppSec teams to avoid potential threats by quickly identifying and mitigating vulnerabilities in newly deployed or updated APIs.

Why This Proactive Approach Is Essential

Continuous API discovery is crucial for ensuring no API goes unnoticed or untested. By continuously monitoring API endpoints, discovery tools help security teams ensure that all APIs are included in security testing, no matter how fast they are developed or how frequently they change.

This proactive approach minimizes the risk of exposure from untracked APIs and ensures that vulnerabilities are identified and addressed before they can be exploited. By providing real-time updates on the API inventory, these tools enable faster response times to security issues, making it easier for AppSec teams to protect the organization’s digital assets effectively.

API Discovery Fosters Collaboration Between Dev, Sec, and Ops Teams

The lines between development, security, and operations are increasingly blurred. However, silos still exist, and these can lead to miscommunication, inefficiencies, and security oversights. API discovery tools are pivotal in bridging these gaps by providing shared visibility into the API landscape across teams. When all teams have access to the same level of visibility about the APIs in use, it fosters better communication and collaboration, fewer misunderstandings, and less miscommunication between teams.

Breaking Down Silos

With API discovery tools, developers, security teams, and operations can all work from a unified inventory of APIs. Developers can quickly identify existing APIs, reducing the likelihood of duplicating effort and ensuring that new APIs are built with awareness of the organization’s current capabilities.

On the other hand, security teams better understand the development process. They can offer more targeted security measures rather than blanket policies that may not fit all scenarios. Understanding the entire API ecosystem benefits operations teams, allowing for better resource allocation and more effective management of API traffic and performance.

The Benefits of Improved Collaboration

This increased collaboration leads to faster identification and remediation of security issues. When security concerns arise, the clear communication channels enabled by API discovery tools ensure they can be addressed swiftly and efficiently. These tools contribute to a more efficient and effective security program by reducing duplication of effort and improving the accuracy of security testing.

As an added benefit, developers and security professionals work more closely together and build mutual respect and understanding, leading to more robust security practices being integrated into the development lifecycle from the outset across the organization.

Regulatory Landscape and API Visibility: Meeting Compliance Requirements

In an era where data breaches can result in hefty fines and irreparable damage to a company’s reputation, regulatory compliance is a non-negotiable. Many industry regulations, such as PCI DSS (Payment Card Industry Data Security Standard), HIPAA (Health Insurance Portability and Accountability Act), and GDPR (General Data Protection Regulation), have stringent requirements around data security and privacy. A key aspect of meeting these requirements is having comprehensive visibility into all APIs within your organization.

API Discovery Tools & Compliance

API discovery tools help organizations maintain compliance by providing a detailed and up-to-date inventory of all APIs. This inventory demonstrates to auditors and regulators that your organization has complete control over its data flows and access points. By ensuring that all APIs are accounted for, documented, and secured, these tools reduce the risk of non-compliance, which can lead to penalties and loss of customer trust.

Moreover, many regulations require regular security testing and monitoring of all potential entry points, including APIs. API discovery tools streamline this process by continuously identifying and cataloging APIs, ensuring they are included in security scans and compliance audits. This proactive approach not only helps in avoiding material exceptions and penalties but also strengthens your organization's overall security posture.

Conclusion

As we discussed in this blog, API discovery tools are indispensable for modern AppSec teams, offering several critical benefits:

Uncovering Shadow APIs: They help identify undocumented and potentially vulnerable APIs that attackers could exploit.
Keeping Pace with Development: These tools automate API discovery and tracking, ensuring that no API is left unchecked, no matter how rapidly your development cycle moves.
Enhancing Team Collaboration: Shared visibility into APIs fosters better communication and collaboration between development, security, and operations teams.
Meeting Compliance Requirements: API discovery tools help ensure that all APIs are accounted for and secured, making it easier to meet regulatory requirements and avoid compliance issues.

Explore StackHawk's API Discovery Capabilities

At StackHawk, we understand the challenges of securing modern applications. Our API discovery tools are designed to help uncover, test, and secure all your APIs in one place, ensuring your organization is protected against emerging threats. With StackHawk, you can gain the visibility and control needed to safeguard your applications and maintain compliance in today’s complex digital environment.

Ready to take control of your API security? Learn more about StackHawk’s API discovery features and see how we can help you secure your applications by starting a free trial today.

Enabling Shift-Left Practices Through AppSec and Developer Training

Matt Thompson

How can StackHawk Customer Success Help Drive More Value?

At the beginning of the year, our team gathered to strategize on what we can do in Customer Success to help our customers maximize their investment in StackHawk. Our primary focus has always been to assist our hawksome customers in achieving their objectives and desired outcomes. Ensuring a successful onboarding experience is critical, as it is with any SaaS platform, and we take great care and pride in our implementation process for all customers. However, our commitment to delivering value extends far beyond just ensuring proper configurations and running tests.

The real benefit of StackHawk lies in helping to unite Application Security (AppSec) and Developers to cultivate a "Shift Left" culture, as outlined in our Senior Director of Product Marketing’s guide, "8 Essential Tips to Evolve your AppSec Program". We mulled over how we could assist AppSec and Developers in embedding security into their software development workflows from the outset. The solution was clear and straightforward - we needed to implement formal training.

Building a Secure Foundation with StackHawk

At StackHawk, our Customer Success team is here to guide you through every step of integrating HawkScan into your software development lifecycle. Our approach ensures your team is equipped with the necessary tools, knowledge, and support throughout the integration.

Onboarding: Though our onboarding process, we help you derive as much value from StackHawk as quickly as possible, and then build from there. This involves inviting your team members, discovering your apps, and laying the groundwork for future growth.
Optimized Setup: We assist you in defining your basic scan configurations, setting up authentication, and tuning your scans for maximum efficiency.
Continuous Adoption: Once you’ve identified how your AppSec and Developers would work together under one common security practice, we’re here to train your entire team on how to bring applications under test and automate in your software development cycle.
Ongoing Support: Your engineers and developers are now empowered to start testing more applications, with continuous guidance and support from StackHawk CSMs and Solutions Architects.
Independence: You’re on the journey from Shift-Left Committed to becoming Continuously Secure as outlined in our Shift Left Maturity Model.

Team Onboarding and Training with StackHawk

Make no mistake, we're well aware that providing a training session isn't exactly groundbreaking. In fact, without the proper context of how you plan to use StackHawk, training sessions can often turn into mundane and repetitive exercises. However, while there are always some fundamental introductory topics that any training must cover, our goal is to ensure that this training is meaningful, hands-on, and engaging. We aim for your teams to dive into testing your critical applications for security vulnerabilities with enthusiasm, aligning seamlessly with your workflows and DevOps practices right from the start.

AJ Stinn, our Lead Support Engineer in our Customer Success team built our Developer Training from the ground up. Here is his approach to get your team started with StackHawk.

“Diving into the world of DAST can feel daunting and complex. It blends elements of AppSec, DevOps, and Engineering, from understanding how your application authenticates to integrating scanning in CI/CD. Without a solid foundation in running scans against an application, it’s easy to feel overwhelmed and unsure of where to start or what to prioritize. Building a well-rounded DAST program that ensures no vulnerabilities are left unchecked while remaining efficient for AppSec and Development requires a solid grasp of the tools, their purpose, and how they function."

"This was my goal when creating our developer training: to ensure the fundamental building blocks are in place for users integrating StackHawk’s DAST into their environment, and to instill the value of shifting this type of security testing earlier in their development lifecycle.”

What is DAST? What is StackHawk?

Attendees might have an idea of Dynamic Application Security Testing (DAST) based on what they’ve heard or other tools they’ve used. We start our training sessions by setting the stage with a clear understanding of StackHawk/DAST and what our platform does—and doesn’t do. This prevents confusion and helps everyone grasp the core purpose of the tooling. We walk through our scanning methodology and explain the architecture of running our DAST engine.

Hands-On Testing

What better way to learn the basics than by testing them out yourself? When covering complex topics in any training, it can be a struggle to follow along with a presenter over Zoom, so we've made it as easy as possible to drive more hands on participation by offering detailed Training Guides accessible in our GitHub repo.These guides outline every training step with easy-to-copy commands that can be pasted directly into your terminal.

Because the long-term vision of running the scanner in a pipeline or navigating OAuth can get quite complex, we stick to the basics during this hands-on portion to drive home the tool's functionality and operation. Engineers install HawkScan and a local testing application. We guide them through setting up and configuring the scanner to work with our application, running a few different scans, and reviewing the findings in the user interface.

Every Organization is Unique

Every organization, its applications, and its development processes are unique. This foundational approach gets attendees thinking critically about their own applications and environments, equipping them with the tools needed to start building complex scanning scenarios tailored to their specific needs. By demonstrating the functionality in a low environment (locally) we are able to directly show the value in scanning applications earlier in the development process. Together this gives attendees the right tools to get started in their journey of Shift-Left DAST.

What are customers saying about the training?

Since formally launching in March, the feedback has been overwhelmingly positive. Here are a couple quotes:

If you've collaborated with our Customer Success Managers, you're aware of how accommodating and flexible we are. Our goal is to make your interactions with our teams both meaningful and goal-oriented. We apply this same philosophy to our training approach.

How can you take advantage?

All new customers will receive this training as part of our standard onboarding process.

If you're already a customer, please contact your dedicated Customer Success Manager or send a message to our support team (support@stackhawk.com or through the chat feature in-app) to arrange a 15-minute session. This will help us tailor the training to better align with your Shift Left objectives.

Prefer a more relaxed setting? Join us for our weekly Wednesday sessions by registering on our website. These sessions are less customized than those scheduled through Customer Success, but are a great start. If you're looking for a more personalized experience, just let us know.

Not a customer yet? No worries! We invite anyone interested in discovering how StackHawk can help you to join this hands-on training session - a perfect opportunity to see what we're all about.

Finding and Fixing SSTI Vulnerabilities in Flask (Python) With StackHawk

StackHawk

For developers building modern web applications, Server-Side Template Injection (SSTI) is a critical vulnerability they should be aware of and carefully avoid. If left unchecked, this vulnerability can lead to significant security issues. SSTI arises when applications unintentionally allow user input to be interpreted as code within server-side templates, creating a potential avenue for attackers to execute malicious actions.

In this blog, we'll dive into Server-Side Template Injection (SSTI) vulnerabilities, exploring their causes and how to identify them within web application code. We'll then use StackHawk to analyze a vulnerable Flask application, pinpoint the SSTI vulnerability, and show you how to fix it. Finally, we'll rescan the application to ensure the vulnerability is resolved. To start, let's clearly understand what an SSTI vulnerability is and why it matters.

What Is Server Side Template Injection (SSTI)?

Server-Side Template Injection (SSTI) poses a significant risk to the security of web applications. This vulnerability arises when an application incorporates user-supplied input directly into its server-side templates without proper sanitization or validation. Template engines, which combine templates with dynamic data to generate web pages, can be exploited through SSTI attacks.

The typical pattern of an SSTI attack involves an attacker analyzing the application's structure and identifying areas where user input might be inserted into templates. They then attempt to inject malicious code, often using the template engine's native syntax, into the input fields. If the application fails to sanitize or escape this input, the injected code can be executed on the server side. This can lead to various consequences, from data leaks and website defacement to full remote code execution, depending on the specific template engine and application environment.

How Does SSTI Differ From XSS?

SSTI vulnerabilities can be easily confused with Cross-Site Scripting (XSS). While both involve injecting malicious code, they differ fundamentally in their targets and potential impact. XSS exploits vulnerabilities in client-side code, injecting malicious scripts into web pages viewed by other users. On the other hand, SSTI targets the server side, injecting code into the templates used to generate web pages. Here’s a table to make it easier to see the difference between the two types of vulnerabilities.

What Are The Root Causes Of SSTI?

Often, it is a combination of factors that lead to SSTI vulnerabilities, including:

Insufficient Input Sanitization: Failure to properly sanitize and validate user-supplied data before incorporating it into templates allows malicious actors to inject executable code.
Dynamic Template Construction: Constructing templates dynamically based on user input can inadvertently introduce vulnerabilities if not handled carefully.
Misconfigured Template Engines: Improper configuration or misuse of advanced template engine features can expose vulnerabilities and create opportunities for SSTI attacks.

Regardless of the exact factors, the root cause of all Server-Side Template Injection (SSTI) vulnerabilities is inadequate sanitization and validation of user-supplied data before it’s used in server-side templates.

How To Prevent SSTI Vulnerabilities

Knowing SSTI vulnerabilities stem from inadequate handling of user input within templates, a holistic approach to building and maintaining your web applications that include secure coding practices, input validation, and continuous security testing is essential. Here are a few key strategies for minimizing your exposure to SSTI vulnerabilities:

Always Use Input Validation and Sanitization: Treat all user-supplied data as potentially malicious and enforce rigorous validation and sanitization procedures to filter out harmful characters and patterns.
Context-Aware Escaping: Encode special characters using the template engine's native escaping mechanisms, preventing their interpretation as executable code.
Content Security Policy (CSP): Employ CSP headers to restrict the sources from which scripts can be loaded, mitigating the potential impact of SSTI attacks.
Principle of Least Privilege (PoLP): Adhere to the PoLP by granting templates only the minimum necessary permissions required for their intended functionality.
Regular Security Testing: Conduct routine security assessments using tools like StackHawk to proactively identify and address SSTI vulnerabilities before they can be exploited.

Following these practices in your application development and deployment lifecycle will improve your resilience against SSTI attacks. Let’s put this into practice by looking at a vulnerable Flask/Jinja application, using StackHawk to identify the SSTI vulnerability, and helping us verify that the fix we will implement successfully remediates the issue.

Detecting And Fixing SSTI Vulnerabilities In Flask/Jinja (Python)

Building The Vulnerable Endpoint

Below is an example of a simple Flask application with an SSTI vulnerability. This application allows users to input their name, which is then rendered in a greeting message using Jinja2 templating. However, it embeds the user input into the template without proper sanitization or escaping, leading to a potential Server-Side Template Injection (SSTI) vulnerability in Jinja2. This scenario illustrates a simple SSTI vulnerability: improperly sanitized user input injected into a template.

Please note: This is an intentionally vulnerable API for demonstration purposes. Do not use this code in an actual application, as it is not production-ready.

First, create a new directory for your project and navigate into it. If you do this through a terminal, you can run the command below.

mkdir ssti-app-example

cd ssti-app-example

Next, point to the root directory with the terminal and initialize a new Python project/virtual environment using the following command.

python3 -m venv myenv

source myenv/bin/activate

Finally, before we write any code, we will install the following dependency:

Flask: This is used to set up the server (this includes the Jinja2 template engine).

To do this, using the same terminal pointed to the project root, run the following:

pip install Flask

Now, we will begin creating our application. In the project's root directory, create a file named app.py. This file will contain your Flask server and the API endpoint, including the SSTI vulnerability.

After creating and opening the app.py file, add the following code:

Let’s do a quick run-through of the code.

Initialization of Flask App
- app = Flask(__name__) Initializes the Flask application, setting up the basic environment for the API server.
API Endpoint Definitions
- @app.route('/') defines a route for the home page (/) which returns a basic HTML form that prompts the user to enter their name and submit it via a POST request
- @app.route('/greet', methods=['POST']) defines a route for /greet that only accepts POST requests. It uses render_template_string to render the greeting message as HTML.

Running The Code

Now that our code is complete, it's time to demonstrate the SSTI vulnerability. Launch the Flask application using the following command in a terminal pointed to the root of your project with your virtual environment still active:

flask run -p 4000

Note that the provided code directly embeds user input (the name variable) into the template without sanitization, thus rendering it vulnerable to SSTI.

To demonstrate this, we can:

Navigate to the root URL (e.g., http://127.0.0.1:4000/) .
Input “{{ 7*7 }}” into the designated field.
Click the X button.

Instead of displaying the expected "Hello, {{ 7*7 }}!", the application will evaluate the injected expression and display "Hello, 49!"

Although not overly malicious, this demonstrates the presence of the SSTI vulnerability within our code. There is the potential that more malicious code could be executed within this application and cause deeper issues. So, let’s take a look at testing for this vulnerability with StackHawk.

Detecting The Vulnerability With StackHawk And HawkScan

Now that our code is set up and our application is running let’s get StackHawk to identify this vulnerability automatically. To do this, you must ensure you have a StackHawk account. If you need one, you can sign up for a trial account or log into an existing account.

If you’re logging into an existing StackHawk account, you’ll click Add an App -> Create Custom App from the Applications page.

If you’re new to StackHawk, you’ll be automatically brought into the Add an App flow. On the Scanner screen, you’ll see the instructions for installing the StackHawk CLI. Since we will be running our testing locally, we will use this option. Once the hawk init command is executed successfully, click the App Details button.

On the next screen, you will fill out an Application Name, Environment Name, and Host. Feel free to copy the default values I’ve added in the screenshot below for our purposes. Once filled out, click App Type.

To detect the SSTI vulnerability, we will set the Application Type to “Dynamic Web Application/Single Page Application” and the API Type to “Other.” Once complete, click Next.

Lastly, we will need to add a stackhawk.yml file to the root of our project. Once the file is added, copy the screen's contents, paste it into the file, and save it. Lastly, we can click the Finish button.

Enabling SSTI Detection in HawkScan

After creating the app in StackHawk, we need to take a few more steps to enable SSTI detection. Two ways to do this are using the "HawkScan Default" policy or customizing an existing policy.

To set HawkScan up with the "HawkScan Default" policy, you will log into StackHawk, go to the Applications screen, and click on the settings link for your application.

Next, on the Settings screen, under HawkScan Settings, click the Applied Policy dropdown and select the "HawkScan Default" policy.

On the next screen, under the Plugins and Tests section, click on the SSTI entry to enable HawkScan to execute tests for potential SSTI vulnerabilities.

For this example, we will need to make a small change and add the following code to the stackhawk.yml file. This configures StackHawk to the base spider and the Ajax spider to discover routes to test.

This configures Hawk Scan to use the base spider and the Ajax spider.

Now, with our application set up in StackHawk, our stackhawk.yml added to the root of our project, and SSTI detection enabled, we can finally test our application.

Run HawkScan

To test our application, in a terminal pointing to the root of our project, we will run HawkScan using the following command:

hawk scan

After running the command, the tests should execute in the terminal.

Explore The Initial Findings

Once the tests are complete, the terminal will contain some information about any vulnerabilities found. Below, we can see that it has identified the SSTI vulnerability that we introduced in the code. To explore this further, we will click on the test link at the bottom of the output. This will take us into the StackHawk platform to explore further.

After clicking the link, we can see the test results nicely formatted. Next, we will click the Server Side Template Injection (SSTI) entry.

Within this entry, we can see an Overview and Resources that can help us fix this vulnerability, as well as the Request and Response that the API returned. Above this, you will also see a Validate button, displaying a cURL command with the exact API request used to expose the vulnerability.

Fixing The SSTI Vulnerability

To fix the SSTI vulnerability, avoid using render_template_string with untrusted input. Instead, use render_template with a predefined template. This allows Flask to escape user input automatically, preventing it from being executed as code. To implement this, update your app.py to the following:

In this secure version, render_template is used with a separate HTML template file (greet.html). Flask passes the name variable to the template, and Jinja2 automatically escapes it, rendering it safe from injection attacks.

After creating and opening the greet.html file, add the following code:

By using render_template with predefined templates, we ensure the template context is escaped correctly. This approach separates user input from template code, mitigating the risk of SSTI. This example demonstrates the identification and remediation of an SSTI vulnerability in a Flask and Jinja2 project.

Once the code has been updated on your side, you can stop the currently running server (by using ctrl + C in the terminal) and restart it with the new code using:

flask run –p 4000

The app should now be up and running with the updated code!

Confirm The Fix

We can run the same test as before and enter {{ 7*7 }} into the input field instead of Hello, 49! we now get Hello, {{ 7*7 }}! as expected.

Now, let’s use StackHawk to confirm that it’s fixed. To do this, we will click the Rescan Findings button back in StackHawk.

Then, we will see a modal containing the “hawk rescan” command that includes the correct Scan ID. You’ll run this command in the same terminal where you ran the initial set of tests.

In the output, you will again see any vulnerabilities in the scan. In this case, the SSTI vulnerability is no longer showing. Clicking on the link at the bottom of the terminal output, you can confirm that the SSTI vulnerability has now been added to the Fixed Findings from Previous Scan section, confirming that the vulnerability has been successfully fixed and has passed any vulnerability tests.

With that, we’ve successfully remedied and retested our application to ensure its safety from potential SSTI attacks. Please remember that the code above is for demonstration purposes only. Carefully validating and sanitizing all user input before it's passed to a template engine is one of the best ways to prevent SSTI and secure your applications. Using a library designed to minimize the risk of overlooking potential vulnerabilities is one of the best ways to mitigate them.

Why StackHawk?

When it comes to preventing vulnerabilities, such as SSTI, StackHawk offers a comprehensive platform for developers to secure their applications and APIs. StackHawk is a modern, powerful DAST tool designed for developers to integrate application security testing seamlessly into their software development lifecycle. It is not just another security tool; it's a developer-first platform emphasizing automation, ease of use, and integration into existing development workflows.

With StackHawk, developers and security teams can:

Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.

Conclusion

In this post, we've explored the critical nature of Server-Side Template Injection (SSTI) vulnerabilities, understanding how they arise from the mishandling of user input within template engines. We've seen their potential for malicious code execution, leading to serious security breaches.

To mitigate these risks, we've emphasized the importance of a robust security strategy, including input validation, secure template engines, and the principle of least privilege. We also demonstrated how StackHawk's dynamic application security testing (DAST) can proactively identify SSTI vulnerabilities, allowing quick remediation. By integrating security best practices and utilizing tools like StackHawk, you can significantly enhance the security posture of your applications, safeguarding them against SSTI attacks. Sign up today to use StackHawk’s modern DAST platform to level up your security game, find SSTI vulnerabilities, and more.

Top 10 API Tools For Testing in 2025

StackHawk

APIs (Application Programming Interfaces) serve as the driving force of modern software systems, powering the digital experiences we rely on daily. To ensure customer satisfaction and product success, it's crucial to guarantee that your APIs are reliable and performant.

API testing is a critical safeguard that ensures your APIs' functionality, security, and efficiency. Choosing the right API testing tool can maximize your product's potential and create delightful user experiences.

This article will discuss the fundamental properties to look for in an API testing tool and how to select the right one for your needs. We will then explore the top API testing tools of 2024, empowering you to make an informed decision. Let's start by taking a deeper look at the fundamentals of API testing.

Understanding API Testing

API testing is a type of software testing that examines the reliability, performance, functionality, and security of APIs. When an API is designed, there are specific expectations for how it should behave. API testing ensures that the API meets these expectations.

In simpler terms, testing an API involves sending requests to it and analyzing the responses. This can be done manually or with the help of automation frameworks. Automated API testing is often used by DevOps, quality assurance, and development teams in continuous testing practices. Later in this article, we'll explore tools that support both manual and automated testing.

One of the main advantages of API testing is that it can detect errors early in the development process, even before the user interface (UI) is ready. This saves significant time and resources, as problems can be addressed quickly. API testing provides rapid feedback, allowing for faster iteration and improvement, which is especially valuable in Agile software development.

API testing can uncover a wide range of issues, including problems with API reliability, slow response times, and security vulnerabilities. By identifying and fixing these issues, you can ensure that data exchanges between software applications are secure and reliable.

API testing tools are essential for ensuring the continued reliability and security of applications. These tools validate the functionality, performance, and security of APIs, helping to maintain high standards for software quality.

Types of API tests

Before releasing your API to production, it's crucial to ensure it will deliver on its promises. API testing involves different approaches to verify the API's functionality and reliability in real-world scenarios.

Functional Testing

Functional testing verifies that the API meets its specific functional requirements. An API can have one or more endpoints associated with different API methods. Together, these endpoints and methods define the API's capabilities and the value it provides users. Effective functional testing ensures that each endpoint functions as intended.

Load and Performance Testing

Load and performance testing assess the API's ability to handle high traffic or stress. By simulating realistic user loads, developers gain insight into how the API performs under expected and unexpected traffic conditions. This type of testing also helps identify potential points of failure, allowing for proactive measures to prevent downtime.

In summary, performance and load testing help you verify:

The API's speed and responsiveness over time.
The API's stability over time.
The API's scalability over time.

Security Testing

Security testing focuses on identifying and mitigating vulnerabilities that could be exploited by malicious actors. These vulnerabilities might lead to unauthorized access, data manipulation, or disruption of normal API operations.

Ensuring API security reduces the risk of cyberattacks and system downtime, improving system integrity and availability. Investing in robust security testing demonstrates a commitment to protecting user privacy, building trust with users and partners, and fostering long-term growth and sustainability.

Although other types of testing do exist, these cover the main types of testing that developers, DevOps, and AppSec teams will perform. Much of the time, teams will use API testing tools to perform these various functions. Next, let's look at some key features to look for in tools you might adopt for API testing.

Selecting an API testing tool that closely aligns with your specific use case is essential. While individual scenarios vary, a good API testing tool should empower you to create, execute, and manage comprehensive tests efficiently. Equally important is the tool's ability to integrate smoothly into your development workflow. Below are a few key considerations to look at when choosing an API testing tool:

Ease of Use

The tool should be intuitive and easy to use, with a minimal learning curve to facilitate adoption. Support for both technical and non-technical users ensures that everyone on your team can quickly adapt and contribute effectively.

Wide Protocol Support

The API testing tool should support a variety of API types, including REST, SOAP, and GraphQL, as well as common data formats like JSON and XML. This ensures compatibility with different API architectures and data structures.

Robust Test Features

Test Creation Flexibility: The tool should offer multiple options for creating tests, such as visual editors and scripting languages. Reusable test components can also enhance productivity.
Data-Driven Testing: As APIs often power data-driven applications, the tool should support data-driven tests to increase test coverage and confidence in the API's behavior.
Automated Testing: The ability to automate test execution, create complex test scenarios, and schedule tests for CI/CD pipelines is crucial for streamlining development workflows and ensuring continuous testing.
Test Data Management: The tool should facilitate the generation, import, and management of test data, including mock resources. This is essential for data-driven testing and simulating various scenarios.
Integration Capabilities: Seamless integration with CI/CD pipelines, version control systems, and other development tools is vital. Without this integration, features like test creation, automation, and data management lose their effectiveness.
Comprehensive Test Support: The tool should support all types of API tests discussed earlier. This includes unit tests and test suites for functional testing, security tests (authentication, input validation, vulnerability scanning), and load/stress tests to assess performance and scalability.

Assertions and Validation

The tool should provide robust mechanisms for validating API responses. This includes checking status codes, data types, and expected behavior to ensure the API functions correctly.

Reporting and Analysis

Comprehensive testing generates a wealth of data. The tool should transform this data into valuable insights through detailed test reports, logs, and visualizations that aid analysis and troubleshooting.

Collaboration

The tool should enable the sharing of tests, results, and test environments among team members to facilitate efficient teamwork.

Monitoring and Alerting

Continuous API monitoring with real-time alerts for issues and anomalies is crucial for maintaining API reliability and performance in production environments.

Customizability and Extensibility

The API testing tool should offer customization options as your product and requirements evolve. This can be achieved through plugins, scripts, or custom code, allowing you to adapt the tool to your changing needs.

Knowing the factors to look for in an API testing tool, it's time to move into the list of tools that encapsulate many of these critical points. Next, let's tackle the top 10 API testing tools available in 2024.

You have a plethora of powerful API testing tools available to choose from. Each offers unique features and capabilities to meet diverse testing requirements. These are the top 10 API testing tools that stand out for their reliability and efficiency:

StackHawk
Postman
SoapUI
JMeter
REST Assured
Katalon Studio
Newman
Apache JMeter
Karate DSL
Apigee
Swagger

Selecting a suitable API testing tool depends on the specific requirements of your project, the expertise of your team, and your testing needs.

StackHawk

StackHawk provides comprehensive security testing for your APIs with DAST (Dynamic Application Security Testing) features. It runs in your CI/CD pipelines and helps you identify vulnerabilities early. Here are some of StackHawk's key features:

StackHawk scans your APIs for common vulnerabilities like SQL injection, (XSS), and insecure configurations before reaching production.
It executes automated security tests in CI/CD so that every code change passes diligent security tests.
StackHawk supports a wide range of API types, including REST, SOAP, GraphQL, and gRPC.
You can customize and extend StackHawk's features to match your security requirements. It integrates with your existing tools and workflows with minimal effort.
StackHawk puts developer experience and productivity at the front. It gives you actionable feedback about your API's security so that you can understand and fix issues as easily and early as possible.

Postman

Postman is a versatile and user-friendly API testing tool that offers a wide range of features to support the entire API lifecycle. Some of its features include the following:

Postman's Collections and Workspaces greatly enhance sharing and collaborative efforts. Collections allow you to organize, reuse, and automate different aspects of your API workflows. Workspaces give you controlled access and environment management as you collaborate with teams, with built-in support for version control.
The ability to quickly create and manage API tests
An easy-to-navigate GUI that makes it accessible for both novice and experienced users

The ability to create mock servers stands out among Postman's salient features. Mock servers allow developers to simulate APIs before actual development. Developers can create rapid prototypes and test API endpoints as part of functional API testing.

Additionally, Postman supports the core features you expect from a comprehensive tool for API testing:

Running requests.
Testing and debugging.
Creating automated tests.
Monitoring REST APIs.

SoapUI

SoapUI is an open-source API testing tool that can efficiently test SOAP, REST, and web services. Its main features include the following:

A user-friendly graphical interface with drag-and-drop features.
Automated functional, regression, and load tests.
Assertions.
Mocking.

One of the key strengths of SoapUI is its assertion capabilities. SoapUI leverages Groovy scripting natively for its built-in assertions and custom scripting, allowing users to create highly customized and flexible tests. You can also use assertion libraries like AssertJ for a more bespoke solution. This combination of features makes SoapUI a suitable API testing tool for both simple and complex testing scenarios.

JMeter

Apache JMeter is a versatile tool widely used for both functional and performance testing of REST and SOAP APIs. By design, it excels in conducting load testing and performance testing under various conditions. So JMeter can become your ideal solution for your API performance testing needs.

JMeter also allows you to utilize CSV files as a test data source. CSV files are very popular in data exchange and data analysis due to their versatility and simplicity. With JMeter supporting CSV files for tests, you have easier access to data-driven API testing.

JMeter has been around for over two decades with a proven industry track record among developers and testers. If you consider the benefits of free, open source, and cross-platform software, JMeter stands out as one of the best API testing tools.

REST Assured

REST Assured is highly regarded among Java developers for automating REST API testing. Its features include:

Expressive syntax that simplifies the creation of API tests.
Built-in support for JSON and XML parsing.
Mock servers integration.

REST Assured also offers seamless integration with the Serenity automation framework and Java testing frameworks like JUnit and TestNG. These integrations further enhances Rest Assured with powerful behavior-driven test features and reliable automation for thorough API testing.

Katalon Studio

Katalon Studio provides end-to-end API testing and builds on top of trust open source solutions like Selenium and Appium. Like Rest Assured, Katalon Studion also supports the Java testing frameworks TestNG and JUnit. This allows developers to test their APIs across different browsers and platforms, including mobile and desktop.

The test recording feature in Katalon Studio allows developers and testers to quickly generate test scripts by capturing interactions with APIs. This not only saves time but allows you to come up with accurate test cases for new product features.

Newman

Newman provides a command-line interface that integrates with Postman.This allows you to automate API testing by running Postman collections in a CI/CD environment. It can execute Postman collections, including requests, scripts, and assertions.

If you're already using Postman as your main API testing tool, then Newman can positively compliment the testing infrastructure you already have.

Karate DSL

Karate DSL is a domain-specific language designed for API testing. It allows developers to create tests using BDD (Behavioral Driven Development) syntax. Karate DSL has built-in support for mocking. You can set up mock servers, dynamically generate responses, and use data-driven mocking using CSV files.

If you want the ability to leverage a tool programmatically and freedom of configuration, then Karate DSL fits right in.

Apigee

Apigee is an API platform that provides tools for designing, building, testing, and monitoring APIs. While it doesn't have built-in traffic simulation, it offers tools for creating and managing mock services that can simulate API behavior. You can execute robust performance tests to ensure your API's performance and reliability.

Apigee particularly suits organizations that require an all-encompassing API platform for comprehensive API testing, management, and monitoring. Its extensive API documentation and monitoring capabilities make it a top choice among developers and testers who need to manage the entire API lifecycle.

Swagger

Swagger offers a toolset designed for API development and documentation. These tools simplify the creation, sharing, and collaboration of detailed REST API documents. By supporting OpenAPI specifications, Swagger streamlines both API development and testing processes. Swagger's tools enable testers, product managers, and developers to effectively collaborate to make sure the APIs remain well-documented and tested.

Swagger UI allows you to generate interactive API documentation from your API's OpenAPI Specification document, and some third-party tools integrate with Swagger to enable the creation of mock servers and test cases based on this documentation.

Choosing the right API testing tool can ensure the quality and reliability of your APIs. We've already discussed the key features to look for in an API testing tool. To make the best choice, consider the following factors:

Project Requirements:

API Types and Protocols: Determine the types of APIs you'll be testing, such as REST, SOAP, and GraphQL, and make sure the tool supports them.
Test Types: Identify the specific types of testing you require—for example, functional, load, and security testing. Make sure the tool offers the necessary capabilities for these types.
Complexity and Scale: Consider the complexity and size of your API project so that the tool can accommodate them adequately.

Team Skills and Resources:

Technical Expertise: Evaluate the technical expertise of your team. Some tools require more coding knowledge than others.
Budget: Consider your budget constraints and choose a tool that balances features and cost-effectiveness.

Tool Features and Capabilities:

Ease of Use: Look for a tool with an intuitive interface and a shallow learning curve, especially if your team has varying technical expertise.
Test Creation and Automation: Ensure the tool provides efficient ways to create and automate tests, including support for scripting, data-driven testing, and integration with CI/CD pipelines.
Reporting and Analytics: Choose a tool with robust reporting and analytics features to gain insights into test results and identify bottlenecks or issues.
Collaboration: If you have a team working on API testing, consider a tool with collaboration features to streamline communication and knowledge sharing.
Integration with Other Tools: Ensure the tool integrates well with your existing development and testing environment. These include version control systems, issue trackers, and so on.

Community and Support:

Community Support: A strong and active community around a tool can provide invaluable resources for getting help, finding solutions, and staying up-to-date with the latest features and best practices.
Vendor Support: If you choose a commercial tool, consider the quality of vendor support available, including documentation, tutorials, and customer support channels.

When selecting an API testing tool, focus on the components most important to your team, whether you choose a complete no-code solution, an automation framework, or a testing platform for web applications. Sometimes, the integration of multiple testing tools may enhance the overall effectiveness of your API testing process.

Best Practices for Effective API Testing

Following some best practices and simple principles during API testing can ensure robust, reliable, and secure APIs for your customers.

Start Early and Test Often

Start testing your APIs as early in the development lifecycle as possible. This approach, known as shift-left testing, helps catch issues early, saving time and resources later. Automate repetitive tests to save time and ensure consistent results.

Prioritize Functional and Performance Testing

Focus on functional tests to verify that your API works as expected, including input validation, data handling, and error responses. Simulate heavy traffic and measure response times, resource usage, and error rates for performance testing.

Perform Comprehensive Security Testing

Perform comprehensive security testing to identify vulnerabilities that attackers could exploit. Test for common weaknesses like injection attacks, authentication failures, and data exposure.

Use Realistic Test Data

Use realistic test data that accurately reflects real-world scenarios and usage patterns. This helps identify potential issues that might not be apparent with artificial or limited data sets.

Maintain Up-to-Date Documentation

Keep your API documentation clear, accurate, and up-to-date. This will help other developers understand and use your API correctly, reducing integration problems and support requests.

Collaborate and Monitor

Collaborate with your team to define clear test objectives and scenarios, ensuring everyone understands the goals and expected outcomes. Monitor your API in production to detect issues early and address them before they significantly impact users.

Next, we will look at a core API testing best practice not mentioned above: Automate API Testing. This particular best practice is extremely important and a core feature you should look for in an API testing tool.

Automating API Tests for Enhanced Efficiency

Consider incorporating automated API tests to boost efficiency in your testing process.

Benefits of Automation

API test automation offers several advantages, including:

Reduced time spent on testing and debugging
Faster feedback on code changes
Quick identification and resolution of issues
Enhanced test coverage across various scenarios
Thorough validation of APIs

Integrating with CI/CD Pipelines

Integrate automated tests into your CI/CD pipelines to validate changes in real-time. Many API testing tools seamlessly integrate with CI/CD, ensuring tests run consistently with every build and deployment. This reduces human error and provides reliable test results. Consider using webhooks to extend your CI/CD capabilities further.

Testing from Within the Code

Automated testing within the codebase can be more effective at identifying bugs in REST API requests than external testing. Integrate feedback-based fuzz testing into your build system to continuously test for bugs caused by unexpected inputs.

Leveraging No-Code/Low-Code Tools

No-code or low-code tools simplify project setup and make automation more accessible to teams with varying levels of programming expertise. This democratizes test automation and empowers more team members to contribute.

Challenges in API Testing and How to Overcome Them

API testing presents several challenges that require careful consideration and proactive solutions:

Lack of Documentation

Incomplete or missing API documentation can hinder testing efforts. Discuss documentation needs with stakeholders early in the development process to ensure that clear and comprehensive documentation is available.

Exception Handling

Properly handling exceptions during API testing is crucial. This involves understanding HTTP status codes and implementing universal error-handling mechanisms to address unexpected responses or errors so that tests don't break the code and stop tests from executing entirely.

Additional Challenges

Other challenges in API testing include:

Understanding API Flows: Grasping how different endpoints interact and communicate internally is essential for effective testing.
Integration Testing: Ensuring correct data flow between multiple systems and APIs requires thorough integration testing.
Frequent Schema Changes: It is essential to update test cases to reflect frequent changes to API schemas, which often involve schema validation assertions.
Comprehensive Test Coverage: Achieving exhaustive test coverage for APIs can be challenging. Prioritize test cases based on different types of tests and risk assessments.
Varying Technical Expertise: Teams with diverse technical knowledge about APIs can face challenges. Consider hiring knowledgeable testers or providing training to bridge the gap. Choosing a user-friendly API testing tool can also help.
Unstable or Underdeveloped APIs: APIs that are still in development or unstable can behave inconsistently. Setting up mock servers with predetermined responses can help test API interactions with other systems, even when the API is not fully functional.

By adopting proper planning, collaboration, and prioritization strategies, you can overcome these challenges and ensure effective and comprehensive API testing.

The Future of API Testing

We're observing emerging trends and technologies that promise to enhance the testing process. No-code development platforms are becoming increasingly popular. These platforms can automate API generation, accelerate time to market, and save time and money. We also see GraphQL becoming popular, offering more control over data fetching compared to REST.

Contract testing have also become increasingly prominent. Since it verifies the interactions between API providers and consumers, it can ensure both parties adhere to a shared agreement. This solves integration issues.

We also see AI-driven testing taking over the market. They offer enhanced error detection, test case generation, and predictive analysis. For example,StackHawk's API Discovery feature uses artificial intelligence to discover and assess APIs within code repositories like GitHub.

These advancements in API testing tools and methodologies have the potential to revolutionize the field. Developers and testers now have more powerful tools and systems for ensuring the reliability and performance of their APIs.

Conclusion

In summary, API testing constitutes an essential aspect of software development that ensures the functionality, security, and performance of applications. By understanding the key features to look for in an API testing tool and carefully considering your requirements, you can pick a tool that's perfect for you.

Choosing from the top API testing tools can only get you so far. The challenges, innovations, and solutions in this space evolve fast. Therefore, it's important to follow the best practices in your testing process and stay abreast of the latest trends. This way, you can truly benefit from modern API testing and solidify your product's sustainable growth.

As a top API testing tool, StackHawk offers a modern DAST platform built for developers and AppSec teams from the ground up. Sign up today to test your APIs for the most pressing vulnerabilities, including those in the OWASP API Top 10.

Announcing API Discovery Powered by HawkAI

StackHawk

Today, we're thrilled to introduce API Discovery Powered by HawkAI, a new AI-driven feature in the StackHawk platform, providing a level of visibility over your API landscape previously unavailable to AppSec leaders.

APIs are crucial for many businesses' most critical applications, yet maintaining a complete inventory of them can be challenging, with many AppSec leaders worrying about unknown APIs slipping through the cracks.

According to market insights from research analyst Melinda Marks at Enterprise Strategy Group (ESG), “87% of respondents are concerned about shadow and undiscovered APIs, with 38% considering it a significant concern and 49% viewing it as a moderate concern”, as shared in "The Urgency of Addressing API Security in an Application Security Program,

The Problem with Not Understanding Your Attack Surface

Not having a clear picture of every API in your attack surface can create blind spots in security coverage, making it difficult to identify and fix vulnerabilities effectively, and accurately report on attack surface coverage, preventing your program from maturing to a continuously secure status.

During our beta testing, we found thousands of unknown or untested APIs in StackHawk customers' code bases. By identifying these lesser-known APIs, customers can significantly boost their security coverage and gain insights that would normally take a year to uncover in just minutes.

How HawkAI Helps

API Discovery Powered by HawkAI acts like a searchlight, revealing every API in your environment and highlighting the most important ones for security testing. Here’s how it can benefit your team:

Enhanced Visibility: Gain a comprehensive, up-to-date view of all your APIs, regardless of origin. No more surprises from third-party integrations or forgotten internal projects.
Security at Ludicrous Speed: Identify and prioritize your most critical APIs for security testing, and fix security bugs faster with frequent testing earlier in the software delivery lifecycle, preventing breaches before they can happen.
Increased Efficiency: Automated discovery frees your team from manual inventory management, allowing you to focus on more important tasks.
Simplified Compliance: Ensure all APIs are identified and prioritized for security testing to meet regulatory requirements, with easier reporting for audits.
Scalability: As your business grows, so does HawkAI. It continuously monitors and catalogs new APIs and development changes, keeping you in control.

"Identifying all APIs and managing them has been a challenge. This feature can automate and improve our process." Lake Setser, Information Security Lead, CommunityAmerica Credit Union

HawkAI: Your API Security Butler

By integrating API Discovery into your workflow, you can achieve unprecedented control and efficiency over your API attack surface. HawkAI ensures your APIs remain secure, compliant, and ready for testing as they evolve.

Ready to Take Flight?

Get started with API Discovery today! Sign up for a free trial or contact us to learn more about how HawkAI can transform your API security practices.

5 Tips for Testing Large Applications and APIs

Nicole Jones

Testing applications becomes exponentially more challenging as they grow in size and complexity. Of course, different types of applications, such as microservices or monolithic applications, have subtle differences in testing approaches, as do testing APIs. Developers and AppSec professionals have many tools and techniques to accommodate applications of all sizes. Still, testing large applications at scale is challenging.

Unlike smaller, self-contained applications, larger and more complex applications demand an extensive and multi-faceted testing strategy. The sheer volume of potential interactions and test cases, ensuring seamless integration between components, and testing performance under heavy loads require a very broad skill set to implement. Overall, when testing applications of this caliber and type, developers must comprehensively understand the technical intricacies and the wider business goals the application is servicing.

This blog post will look at various angles of testing applications and APIs at scale. We will examine the unique challenges that larger and more complex applications bring and why testing is integral to building and supporting these apps. Lastly, we will look at five practical tips you can apply to ensure your applications are being tested thoroughly and from multiple angles. Let’s begin by looking at some of the unique challenges of testing at scale.

The Unique Challenges of Testing at Scale: How Large Applications and APIs Change the Game

Testing large applications and APIs is not as easy as scaling up traditional testing methods. At scale, some of these methods can’t deliver the benefits they do in typical, smaller application environments. The intricacies of larger systems and API portfolios introduce a distinct set of challenges that demand a more sophisticated, comprehensive approach. Let's look at the key differences that set large-scale testing apart:

Scale and Complexity:
- Codebase: Large applications have extensive codebases with numerous modules, components, and dependencies. This creates a web of potential interactions that must be meticulously tested individually and once integrated with other components.
- User Interactions: The sheer number of users and the diverse ways they interact with the application introduce many scenarios to consider when creating test cases. This leaves teams to test everything from simple tasks to complex workflows.
Data Volume:
- API Data Handling: APIs often act as conduits for massive amounts of data in terms of storage and transmission. Ensuring this data's accuracy, integrity, and security throughout its lifecycle (in transit, at rest, within logs, etc.) is critical to maintaining overall security.
- Database Interactions: Testing the application's ability to efficiently query, update, and retrieve data from potentially massive databases becomes critical. Testing queries and integrations between the code and database for performance and accuracy with larger volumes and data variations is also vital for diagnosing any issues.
Integration Points:
- Microservices: Many large applications adopt microservices architectures, where numerous independent services communicate. Mapping out and testing the interactions between components requires a comprehensive understanding of the interdependencies and potential points of failure. In systems with potentially hundreds or thousands of microservices, unit and integration test coverage can become complex to track and achieve.
- Third-party Services: Large applications often rely on external services for functionalities like authentication, payments, or notifications. Testing these integrations demands careful coordination and consideration of potential outages or changes in the third-party APIs. Ensuring that fallback or cases where an error occurs is critical for test cases.
Performance Considerations:
- Scalability: Large applications must be designed to handle increasing user loads without sacrificing responsiveness or stability. Load testing and performance monitoring become indispensable to ensure the system scales up to and beyond the anticipated volumes. This becomes exponentially more complex as concurrent users scale into the thousands or even millions.
- Resilience: Testing for resilience involves simulating various failure scenarios (e.g., network disruptions and hardware failures) to ensure the application can recover quickly and minimize downtime. Testing disaster recovery and fallback mechanisms across all components (application servers, databases, etc.) requires significant planning when applications are larger and have more elements to consider.

These challenges highlight why specialized testing strategies, tools, and expertise are needed when dealing with large-scale applications and APIs. As applications have become larger and more complex, application and API testing tools and techniques have also evolved to accommodate these particular challenges. Sometimes, the complexity of testing these applications means that teams forego testing or underestimate the impact of comprehensive testing for these larger applications. Next, we will examine why testing these apps is critical for success.

Why Software Testing is Important for Success at Scale

When building large applications and API portfolios, the impact of potential issues is exponential as the user base or application criticality increases. The stakes are higher, the possible consequences of failure are more significant, and the need for quality assurance and testing is the main barrier between success and failure. Let’s look at a few reasons why testing larger applications comprehensively is essential.

Quality Assurance

Meeting Expectations: Large applications are often mission-critical for businesses or serve large user bases. A comprehensive testing strategy ensures that the application and APIs function as intended, meeting both functional and non-functional requirements.
Minimizing Defects: Identifying and addressing bugs and errors early in development, a key factor in the “shift left” movement, is far more cost-effective than dealing with them in production. Once they’ve made it to production, they can cause significant disruptions, financial losses, and damage to a company’s reputation.

Risk Mitigation

Early Issue Detection: Thorough testing uncovers vulnerabilities, security flaws, and performance bottlenecks before they escalate into major problems. Depending on what component issues are detected, a proactive approach significantly reduces the risk of downtime/outages, data breaches, or system failures.
Protecting Reputation: News of major software failures spreads rapidly and can create lasting damage to customer trust. Comprehensive testing safeguards the organization's reputation by ensuring a system is reliable and user experiences and data are secure.

Cost Savings

Defect Prevention: Catching issues early during testing cycles helps prevent them from propagating throughout the codebase. Early detection generally makes fixes simpler and less expensive than if the bug is able to reach production. This translates to significant cost savings over the long run.
Optimized Development: Testing provides rapid feedback to developers, allowing them to identify and rectify issues quickly, streamlining the development process and reducing time-to-market. Catching issues later in development could lead to significant refactors to remedy them, leading to developers spending more time fixing issues. There are also ripple effects for testing that was already completed since it might need to be redone if the refactor touches other parts of the system.

Customer Satisfaction

Positive User Experience: A well-tested application delivers a smooth, reliable, and enjoyable experience for users. Users expect a seamless experience and when not delivered, this can lead to bad reviews and other reputational damage. Testing with user experience in mind is critical.
Competitive Advantage: With such a competitive landscape, software quality can be a key differentiator. A reputation for delivering stable and scalable software can attract and retain customers, giving your organization a significant edge over other applications that might not be tested as thoroughly.

Successful large-scale software development requires attention to detail when it comes to testing. Instead of foregoing or underinvesting in testing larger applications and APIs, you can build applications that are future-proofed and easier to maintain by recognizing the critical role of testing and embracing a comprehensive testing strategy. So, what approaches should you take to ensure that your large applications and APIs get the testing they deserve? Let’s look at five tips to get you down the right path.

5 Tips for Testing Large Applications and APIs

#1: Generate and Maintain Comprehensive API Specifications

API specifications serve as the blueprint for communication between your application and the outside world. Over the years, various types of API specs have appeared, but all do the same thing: define the contract between the client and the server. They help to outline how data is exchanged, what functionalities the API exposes, and how errors are handled. For large, complex applications and APIs, well-built API specifications are essential for developers to understand the API they are consuming and also for testing tools that use API specifications to create tests.

These specifications should include:

Endpoints (URLs and supported HTTP methods)
Request and response formats (typically JSON or XML)
Data types for parameters
Authentication and authorization mechanisms
Potential errors that can be returned by an endpoint

Comprehensive API specs offer numerous benefits, including improved collaboration between teams, faster development, easier testing, and simplified integration for API users. Many API testing tools can use these specs to directly build tests. To create and maintain these, adopt a standard format like OpenAPI (Swagger), document all aspects thoroughly, use examples, implement versioning for the spec, and consider automating the generation or validation of specifications.

#2: Ensure Complete API Coverage with Discoverability Tools

Large applications and APIs may have hundreds or even thousands of endpoints. Ensuring complete test coverage is a challenge, but discoverability tools can automate the process of identifying, documenting, and testing every endpoint, especially those that are undocumented or hidden.

These tools can scan for potential API endpoints via crawling, code analysis, and other mechanisms. The results of API discovery can help identify hidden or undocumented endpoints, generate documentation for each endpoint, and even automatically create test cases. By identifying all endpoints, you can ensure that test coverage is truly sufficient. You may also find that undocumented endpoints aren’t even used so they can be decommissioned, reducing the codebase and number of tests that need to be executed.

Choosing a tool like StackHawk, Postman, Swagger UI, or Stoplight can bring API discovery into your organization. These tools can help you explore your APIs, document each endpoint, and, in the case of StackHawk, create security test cases to ensure endpoints are secure. Larger API portfolios and apps run a higher risk of having undocumented APIs that lack proper testing, especially when distributed across teams. API discovery tools can help to curb these issues.

#3: Implement Automated Testing Pipelines

Manual testing is unsustainable for large applications. Although certain aspects of testing might still be handled manually, automated testing pipelines streamline quality assurance by automatically executing various tests (unit, integration, end-to-end, and security testing) whenever code changes are made. These pipelines, often integrated with version control and CI/CD tools, trigger tests with every commit or merge. This allows developers to write code as they normally would but have automated processes in place to give them feedback.

The benefits of this feedback numerous: faster feedback for developers, improved code quality and security, increased efficiency, better testing coverage, and lower costs when it comes to creating software.

To implement automated testing, there are many tools to pick from, covering various aspects of testing. The first step is to choose a suitable framework or tool (e.g., Selenium, Cypress, JUnit, StackHawk), write comprehensive test cases or configure the tool to do so for you, integrate the tests/tool into your CI/CD pipeline, and analyze any reports generated to address any areas of concern or test failures.

#4: Use Mock Servers and Virtualization

When it comes to testing large applications and APIs at scale, it’s crucial to simulate real-world scenarios as closely as possible. However, testing in such scenarios can be challenging due to external dependencies. To overcome this, employing mock servers can be advantageous as they simulate external services by returning predefined responses. Additionally, leveraging virtualization helps create isolated environments that mimic production settings.

Combining these techniques allows for consistent testing at scale without the influence of third-party dependencies skewing results due to outages, performance issues, etc. While this approach does minimize the need for frequent integration testing with external services, critical integrations should be tested early and repeatedly. This strategy ensures reliability, speed, flexibility, and isolation in testing. Tests remain reliable even when external services are down, and mock servers facilitate quick response times, enabling easy simulation of all possible test scenarios that include third-party integrations. Virtualization focuses tests on your application's behavior in isolation.

To build this testing functionality out, utilize tools like WireMock, Mockoon, or Prism to define mock responses and configure virtual environments (e.g., using Docker or Vagrant) for integration into automated tests.

#5: Incorporate Load Testing and Performance Monitoring

Large applications must handle heavy traffic loads. As part of a holistic testing process, load testing simulates realistic user traffic to assess performance, while performance monitoring tracks key metrics in production.

This is crucial for ensuring scalability, reliability, and a positive user experience. Load testing helps identify bottlenecks and optimize for peak traffic, while monitoring allows for proactive detection of performance issues.

Select load testing tools like JMeter, LoadRunner, or Gatling. Define realistic test scenarios, execute tests with increasing loads, analyze the results, and implement performance monitoring tools (e.g., New Relic, Datadog, Prometheus) in production.

Using StackHawk to Test Large Applications and APIs

When it comes to large-scale applications and APIs, attack surfaces can be vast, and the potential for vulnerabilities is high. Ensuring that an application is secure is critical for performance and customer trust, especially as a user base expands or an application becomes mission-critical for users.

This is where StackHawk steps in with its modern dynamic application security testing (DAST) platform and API testing tool suite, leveraging cutting-edge technology to proactively identify and address security risks, including extensive REST API testing capabilities.

How StackHawk Enhances Application and API Testing

API Discoverability: One of the key challenges in testing large applications is ensuring comprehensive coverage of all API endpoints. StackHawk's automated API discovery feature, powered by HawkAI, scans your repositories to identify all available APIs, including those that might be undocumented or hidden. Adding this to your API testing process ensures that your security and performance testing efforts are comprehensive and leave no endpoint untested.
Automated Security Testing: StackHawk's intelligent testing simulates real-world attacks against your APIs. Use API tests to identify vulnerabilities such as injection attacks, cross-site scripting (XSS), insecure deserialization, and more. By using API test automation, StackHawk saves you valuable time and effort, allowing you to focus on building features while ensuring your application and APIs remain secure.
CI/CD Integration: StackHawk integrates seamlessly into your CI/CD pipeline, enabling you to automate security and performance testing with every code change or deployment. This continuous testing approach ensures that vulnerabilities and performance issues are identified and addressed early in the development cycle before they have the chance to reach production.

Conclusion

The complexities of testing large applications and APIs demand a strategic and comprehensive approach. Depending on the scale and complexity of an application or portfolio of APIs, testing can become exponentially tougher to ensure that it is holistic and covers every angle. By using the five essential tips we talked about in this guide, building large-scale software that is not only functionally sound but also resilient, secure, and performant is easier than one might think. As your application and APIs evolve, testing practices must evolve alongside it. Embrace automation, utilize the right tools, and foster a culture of quality and secure coding practices.

Ready to take your large application and API testing to the next level? Plug in StackHawk into your testing stack to ensure your applications are secure from the most critical threats. Add StackHawk into CI/CD to test and deliver reports to developers so they can find, triage, and fix defects before they have a chance to hit production. Sign up today and try StackHawk out for 14 days for free.

How To Discover Your API Attack Surface

Nicole Jones

APIs (Application Programming Interface) are the glue of most applications, making functionalities and data communication possible. Powering everything from mobile and web apps to complex enterprise systems, APIs are the most critical part of modern applications. But as their use explodes, so does their potential to be attacked. An API call that exploits a single API vulnerability can expose sensitive data, disrupt services, or even destroy entire infrastructures.

In this post, we'll unpack API security and API attack surfaces in a practical and informative way. We'll define key terms, explore common API attack vectors and the vulnerabilities they prey on, and provide strategies to protect your API ecosystem. Whether you're an AppSec pro or a developer, understanding and mitigating these risks is crucial to building secure web applications.

Understanding API Security

Before we discuss API attacks and vulnerabilities in detail, let's establish a solid foundation by defining the core concepts of API security.

What is API Security?

At its core, API security is a set of practices designed to protect APIs from unauthorized access, misuse, and attacks. It encompasses everything from authentication and authorization mechanisms to data encryption and input validation. API security is critical to API development, deployment, and support.

Importance of API Security in Modern Applications

The reliance on APIs makes their security crucial. When an API is compromised, it can impact technical and business operations heavily. When an API attack is successful, organizations can expect:

Data breaches: Exposure of sensitive user information or confidential business data.
Service disruptions: Denial of service attacks or malicious activities can disrupt API availability.
Financial losses: The cost of recovering from a security incident can be substantial.
Reputation damage: A security breach can erode customer trust and harm your brand's image.

Because of these implications, API security should be a top priority for every organization. Foregoing preventative measures to secure APIs and robust monitoring are risks that shouldn't be taken. To ensure that APIs are well secured, the first step is to understand your API attack surface. Let's dig into what that means.

The API Attack Surface

Understanding the API attack surface is like mapping the perimeter of a network. It reveals all the potential entry points where malicious actors might try to breach your defenses. Let's look at the key components of this critical API security aspect.

Definition of an Attack Surface

In the context of API security, the attack surface area refers to the total sum of all vulnerabilities and weaknesses that could be exploited by attackers. It encompasses both the technical aspects of the API implementation and the surrounding infrastructure.

An API's attack surface consists of various elements that attackers can target, such as:

Endpoints and Methods: These are the specific URLs and actions (GET, POST, PUT, DELETE, etc.) that clients use to interact with the API. If not properly secured, API calls can be exploited to access sensitive data or manipulate the API's functionality.
Input Parameters: The data clients send in an API request, such as form fields or query parameters, can be manipulated to inject malicious code or trigger unintended behavior.
Authentication and Authorization: These mechanisms control who can access the API and what they can do. Weak authentication can allow attackers to impersonate legitimate users, while flawed authorization can grant excessive privileges.
Data Storage: The databases and other systems where the API stores data can be targeted for unauthorized access or modification.
Network Infrastructure: The servers, routers, and firewalls that support the API can be attacked to disrupt its availability or intercept data in transit.

The attack surface encapsulates every piece of the API code, implementation, and infrastructure. So how does this relate to API security?

How an Attack Surface Relates to API Security

The concept of the attack surface is fundamental to API security because it highlights that security is not just about protecting a single point of entry. It's about securing every potential avenue of attack, from endpoints to configuration settings.

By having a holistic understanding of the attack surface, you can:

Prioritize Risks: Identify the most critical vulnerabilities and address them first.
Implement Layered Security: Deploy multiple security mechanisms to create a defense-in-depth strategy.
Continuous Monitoring: Regularly assess all angles of the attack surface for new vulnerabilities and adapt your security measures accordingly.

It's important to note that the attack surface is not static, so the API security approach needs to be dynamic. This dynamic nature results from API changes to code and infrastructure and new threats emerging. Therefore, education, ongoing vigilance, and proactive security measures are essential to keeping your APIs safe. Next, let's look closer at API security risks and vulnerabilities.

API Security Risks and Vulnerabilities

API code and infrastructure are complex, leading to a complex attack surface. This diverse attack surface creates numerous security risks and vulnerabilities. Understanding these risks is crucial for prioritizing mitigation efforts and establishing effective security practices. Regarding vulnerabilities, we will look at the OWASP API Top 10 and then dig further into one of the most common areas for security gaps in APIs: authentication and authorization flaws.

OWASP Top 10 API Security Risks (2023)

The Open Web Application Security Project (OWASP) lists the top 10 most critical API security risks. In 2023, OWASP released a new iteration of the list they started in 2019 to align with the latest issues being observed. These include:

Broken Object Level Authorization: Unauthorized access to resources due to insufficient object-level authorization checks.
Broken Authentication: Flaws in authentication mechanisms allowing attackers to compromise authentication tokens or assume other users' identities.
Broken Object Property Level Authorization: Inadequate authorization controls at the property level, allowing attackers to gain unauthorized access or modification of object properties.
Unrestricted Resource Consumption: Lack of resource and rate limiting, leading to denial of service (DoS) attacks or excessive resource usage.
Broken Function Level Authorization: Missing or ineffective authorization checks on API functions, allowing unauthorized access to sensitive operations.
Unrestricted Access to Sensitive Business Flows: Exposure of critical business processes through the API without proper protection, enabling unauthorized actions or data manipulation.
Server-Side Request Forgery (SSRF): Vulnerabilities allowing attackers to force the API server to make requests to arbitrary internal or external systems.
Security Misconfiguration: Errors or oversights in the configuration of the API or its infrastructure, such as default credentials or exposed debugging endpoints.
Improper Inventory Management: Lack of visibility and control over API versions and deployed assets, leading to potential vulnerabilities in outdated or unused endpoints.
Unsafe Consumption of APIs: Client applications consuming APIs without proper validation or sanitization of data, opening the door for injection attacks and other vulnerabilities.

Authentication and Authorization Weaknesses

Authentication and authorization are fundamental pillars of API security. However, they are also common areas where vulnerabilities arise and are exploited. Here are some specific weaknesses to be aware of:

Weak Passwords: Easily guessable or short passwords can be quickly cracked by attackers.
Lack of Multi-Factor Authentication (MFA): Relying solely on passwords for authentication leaves APIs vulnerable to credential theft.
Insecure Token Management: Improperly generated, stored, or transmitted tokens can be intercepted or stolen.
Role-Based Access Control (RBAC) Misconfiguration: Incorrectly assigning roles or permissions can give users more access than they should have.
Inadequate Session Management: Weak session management can allow attackers to hijack legitimate user sessions.
Lack of Input Validation: Failing to validate input, especially for security credentials, can lead to injection attacks or other forms of data manipulation.

By understanding these risks and vulnerabilities, you can proactively implement security measures to protect your APIs from these issues. Of course, since many of these issues are well-known, there are many ways to solve them and prevent them from becoming a problem in your APIs. In the next section, we will explore best practices for securing your APIs and mitigating these risks.

Securing Your API: Best Practices

With the complexities that come with securing APIs, best practices for API security cover everything from automated testing and monitoring at the code level to adding pieces of infrastructure, such as API gateways, to mitigate risks. We won't dive into an extensive list, but let's take a look at some staples you should definitely consider when securing APIs.

Use API Discovery to Understand the Full Picture

Before you can secure your APIs, you need to know what APIs you have and where they reside. API discovery tools, like the one included in StackHawk, automatically scan your network, code repositories, and even runtime traffic to identify all APIs, including hidden or shadow APIs that might have been forgotten or undocumented.

Understanding the full scope of your API landscape is essential for effective risk assessment and security planning. It allows you to:

Identify all potential attack surfaces: Uncover hidden endpoints, outdated versions, or misconfigurations that could be exploited.
Prioritize security efforts: Focus on the most critical APIs that handle sensitive data or perform essential functions.
Ensure comprehensive security coverage: Verify that all APIs are protected by appropriate security measures, including those you may not be aware of.

Leverage Automated Security Testing

Manual security testing can be time-consuming and error-prone. Automated security testing tools, like StackHawk's dynamic application security testing (DAST) engine, can quickly and efficiently scan your RESTful, SOAP (Simple Object Access Protocol), RPC (Remote Procedure Call), and GraphQL APIs for vulnerabilities, including those listed in the OWASP Top 10. Combining multiple automated api testing methods, such as also using a platform like Snyk's static application security testing (SAST), can help to automate coverage from multiple angles.

By integrating automated security testing into your development pipeline, you can:

Catch vulnerabilities early: "shift left" and identify and fix security issues before they reach production.
Reduce the risk of human error: Automate repetitive tasks, especially by running tasks in CI/CD pipelines, and ensure consistent testing coverage on every commit, pull request, or deployment.
Improve security posture: Continuous testing helps detect new vulnerabilities and adapt your security measures accordingly.

Implement Secure Authentication and Authorization

Robust authentication and authorization mechanisms are essential for controlling access to your API and preventing unauthorized actions. Consider adding the following measures to your API auth:

Strong passwords and MFA: Enforce the use of strong passwords and implement multi-factor authentication wherever possible.
OAuth 2.0 or OpenID Connect: Use industry-standard protocols for secure token-based authentication and authorization through platforms like Okta and Auth0.
Role-Based Access Control (RBAC): Define granular permissions based on user roles to limit access to sensitive resources.
JWT (JSON Web Tokens): Use JWTs for stateless authentication and authorization, ensuring secure transmission of claims and user information.

Use HTTPS and Rate Limiting to Prevent Abuse

Always encrypt API traffic using HTTPS to protect data in transit and prevent eavesdropping or tampering. Additionally, rate limiting should be implemented to restrict the number of API requests or calls an API client can make within a given timeframe. This can help mitigate denial of service attacks and prevent abuse. One of the easiest ways to do this is to integrate your APIs with an API gateway like the ones offered by Kong, Tyk, or WSO2.

API Key Management and Secure Data Handling

Another functionality offered through API gateways, developers can protect API keys by storing them securely in a key management platform and rotating them regularly. Never embed API keys directly in code, especially when committing the code to public repositories, or transmit them in plain text. Implement strong encryption for sensitive data at rest and in transit, and follow secure coding practices to prevent vulnerabilities like injection attacks.

Regular Security Assessments and Monitoring

Make security an ongoing process. Regularly assess your API's security strategy and posture using tools like StackHawk to identify new vulnerabilities and other tools to help monitor for suspicious activity in API traffic and infrastructure access. Keep your API infrastructure and dependencies up to date to patch known security flaws.

By adhering to these best practices and leveraging tools like StackHawk's API discovery and DAST capabilities, you can proactively secure your APIs, protect sensitive data, and ensure the reliability of the applications that depend on your APIs.

Conclusion

API vulnerabilities pose a significant threat to modern software. By understanding the API attack surface, recognizing common attack vectors, and proactively implementing best practices, you can effectively mitigate these risks and safeguard your valuable assets.

API security is an ongoing effort, not something you set and forget. API Developers and the teams that support them must stay vigilant, leverage powerful tools like StackHawk to continuously monitor and improve their API security posture, and empower their development teams to build secure applications.

Ready to take the next step in understanding your API attack surface and securing your APIs? Try out StackHawk today to leverage DAST and API Discovery to up your API security posture.

What is REST API Testing? Tools and Best Practices for Success

StackHawk

APIs (Application Programming Interfaces) are the glue that holds applications and services together. With the growth of distributed, multi-tier architectures, APIs are a crucial piece of modern applications, usually encompassing a good chunk of an application's logic and business processes. One of the most popular architectural styles for building APIs is REST (Representational State Transfer), known for its simplicity, scalability, and stateless nature. RESTful APIs facilitate communication with internal applications, support data integration workflows, and play significant roles in app development and data pipelines.

However, with the increased complexity and dependency on REST APIs, ensuring their quality, security, and performance is now critical to the software development lifecycle. This is where REST API testing comes into play. Testing your APIs is not just a best practice; it is essential for delivering reliable, secure, high-performing APIs that meet user and business expectations. Comprehensive testing throughout the entire API lifecycle—from design to deployment—ensures that APIs function as intended as they are designed, built, and deployed.

In this article, we’ll dive into REST API testing from various angles, looking at the fundamentals, best practices, and tools that can be used in your testing efforts. Let’s begin by digging into some high-level topics revolving around API testing.

What is API Testing?

API testing focuses on validating the functionality, reliability, performance, and security of application programming interfaces (APIs). Unlike UI testing, which focuses on the visual aspects of an application and related flows, API testing targets the logic and data layers of an application. It involves sending requests to API endpoints and analyzing the responses to ensure they meet the expected criteria in terms of usability, performance, and reliability.

API testing should be a regular part of building APIs, preferably testing at various stages of API development. API testing is vital for:

Core Functionality: APIs are the building blocks of applications. Thorough testing ensures that each API endpoint does its job in terms of required functionality.
Data Accuracy: APIs read and write data. API testing verifies that the data written to a database or returned from one is accurate, complete, and formatted correctly.
Error Handling: Errors can occur unexpectedly. API testing checks how the API handles errors and how they are presented to users.
Security: APIs can be vulnerable to attacks. Testing helps identify security flaws, such as unauthorized access, data leaks, and injection vulnerabilities.
Performance: APIs must be responsive under load and at scale. Performance testing measures how well the API performs under different levels of traffic.

Benefits of REST API Testing

By testing at various stages, API testing brings many benefits to developers and their organizations. A few of the most prominent benefits include:

Early Bug Detection: Catching and fixing bugs early in development is much cheaper, more efficient, and less risky than finding and fixing them in production. API testing helps catch issues before they make their way onto production servers and impact end users.
Better Software Quality: Thorough testing ensures the overall quality and reliability of your APIs for a better user experience.
Better Security: By finding vulnerabilities during testing, you can take proactive measures to secure your APIs to ensure that critical security issues are remedies before they can be exploited in production environments.
Faster Development: Testing APIs early and often allows for faster development cycles. By automating parts of API testing, certain tests can be run in a matter of seconds or minutes, allowing developers to identify and remedy bugs and gaps in functionality early on in the SDLC.

To fully realize these benefits, different types of API testing need to be performed as APIs are developed and published. Let’s take a look at those particulars in the next section.

Types of API Tests

REST API testing involves various types of tests, each serving different purposes. Each testing type helps ensure the overall quality and functionality of your APIs from different angles. Let’s look into some of the most common and essential types of API testing.

Unit Testing

At the most basic level, unit testing involves testing individual components or operations of an API. It ensures that each isolated part of the API works as expected and validates the logic and expected behavior. Developers are usually familiar with this type of testing and the frameworks that can be used to implement it. These tests are usually written by developers and aid in ensuring that the code itself is adhering to the functional needs of the application.

Integration Testing

As the name suggests, integration testing checks how different API components or modules work together and with other parts of the system. Integration tests help to verify the interactions between various endpoints and check for data flow, error handling, and overall system integration. This testing is still likely performed by developers and might include automated tests and manual test cases to ensure that systems can be integrated as required.

Functional Testing

Functional testing involves verifying that the REST API behaves according to its functional requirements. This involves testing the API with different inputs, ensuring it returns the correct output, handles edge cases, and follows the business logic. This may sometimes overlap with the business acceptance testing phase of a project where the group that the application is being built for does preliminary testing to ensure that it fits their needs.

Load Testing

Load testing tests the REST API under expected and peak traffic. Testing REST API performance is vital to ensure stability and responsiveness under different load scenarios. It helps to determine the API’s capacity, response time, and stability under a high volume of requests. For this type of testing, developers and testers usually use an automated approach to produce the API requests to push load onto the endpoint and the server. Quite a few tools exist, some simple ones and more advanced ones, which can help to make load testing easier.

Security Testing

Security testing is essential to protecting REST APIs from vulnerabilities and malicious attacks. This involves testing for common security risks, such as injection attacks, cross-site scripting (XSS), authentication and authorization issues, and data exposure. Luckily, OWASP publishes a list of the top 10 API vulnerabilities that many security testing tools use as a guide to help developers automate detecting the most pressing vulnerabilities. Security testing can involve automated testing, such as using a Dynamic Application Security Testing (DAST) tool, or manual penetration testing performed by API security testers.

Each type of API testing is essential in the overall testing strategy for REST APIs. By combining these tests, organizations can be confident in their API’s functionality, performance, reliability, and security. Testing does come with its share of challenges, though. In the next section, we’ll examine some of the difficulties in testing REST APIs and how to overcome them.

Challenges in Testing REST APIs

While REST APIs are at the core of most modern architectures and have many benefits, testing them can be challenging. Let’s look at some of these challenges in more detail below.

API Parameter Combinations

REST APIs can use multiple parameters within an API call, including query parameters, request body fields, and request URIs. Combining these parameters creates numerous possible scenarios that need testing, and testing all combinations efficiently can be challenging. With the advent of AI and testing tools, this can be easier, but it still represents a challenge to test every combination for more complex APIs.

Validating API Parameters

Another challenge is validating the parameters passed to REST APIs. Incorrect data types, invalid values, or unexpected parameter combinations can cause errors or unpredictable behavior. Validating REST API parameters is essential to addressing these issues. However, it is challenging to validate parameters and ensure any incorrect parameters are handled correctly. Testing as many variants as possible to test all logic paths and parameter validation is important to prevent vulnerabilities and make the API robust.

Maintaining the Data Format Schema

REST APIs use data format schemas like JSON or XML, the most popular of which is documenting the APIs through an OpenAPI spec. However, as the API evolves, maintaining the schema’s consistency and accuracy is challenging. When the schema changes, developers and testers may be required to update test cases and validation mechanisms based on the latest spec. This can introduce errors and gaps in testing if not managed carefully.

Testing API Call Sequences

In many cases, REST API calls need to be executed in a specific sequence to achieve the desired outcome. For APIs that require calls to be chained together to test a specific logic flow, testing these call sequences manually can be challenging and error-prone. Testing REST API call sequences is important to detect any errors, logic flaws, or security issues, especially in multithreaded operations. Automating the testing of complex call sequences is important to ensure functionality requirements are met and prevent regressions.

API Testing Setup

Setting up a REST API testing environment can involve many manual steps, especially for larger projects. Configuring test data, managing dependencies, and integrating with other systems can be time-consuming. This includes managing licenses and subscriptions for testing platforms, as well as deploying and configuring these platforms, all of which put extra work on the plates of developers and testers.

Not All Testing Provides Code-Level Insights

Traditional black box testing tools may not provide deep insights into the internal workings of REST APIs, making it difficult to identify the root cause of errors. Coverage-guided testing and white box testing can help overcome this challenge by providing more detailed error reports and better test coverage.

These challenges show the complexity of testing REST APIs. However, by using the right strategies and tools, these challenges can be overcome. Despite the challenges, API testing is a must-have for building robust, secure, and high-performing APIs. In the next section, we will examine some API testing strategies for overcoming these challenges and creating a holistic testing strategy.

API Testing Strategies

When it comes to API testing, certain strategies can work well across the board. Of course, the exact strategies you implement will depend on factors such as API complexity, infrastructure and programming languages you’ve used, and even your team's level of expertise. Let’s take a look at a few strategies you can implement to make your testing comprehensive and efficient.

Fuzz Testing

Fuzz testing, also known as fuzzing, is a technique where you inject invalid, unexpected, or random data into the API request. This helps to find vulnerabilities and unexpected behavior. Feedback-based fuzzing is a more advanced approach in which factors such as code coverage measure testing progress. Feedback-based fuzzing solutions use this info to guide the generation of new test cases based on feedback from the existing test cases. Overall, fuzzing helps to find bugs and security issues caused by unexpected inputs and makes the API more robust and stable.

Automating API Testing

Although necessary for certain types of testing, manual testing of APIs is time-consuming and error-prone. This is especially true for large and complex APIs. Implementing test automation as often as possible is the key to a scalable and consistent testing strategy. Automating API testing allows faster execution of test cases, more test coverage, and early detection of regressions. Automation tools can simulate scenarios, validate responses, and generate detailed reports to inform developers and stakeholders about the current state of the application being tested. Adding automated methods helps make the API testing process more efficient and faster.

Testing Before Deploying vs. After Deploying

Testing APIs at various stages of development and deployment is also crucial to detecting issues. Since different environments can affect the results of tests, such as performance and security, testing can be done before and after deploying RESTful APIs to various environments, including production. Testing before deploying (pre-production testing) includes unit testing, integration testing, and other types of testing to ensure the API works as expected in a controlled environment. Testing after deploying (post-production testing) is testing the API in the real world, under real conditions. At this point, testing the API for performance under load and finding issues that may occur in production can be performed. Security testing is one type that should be performed pre and post-deployment to production to ensure that vulnerability detection is in force through all environments. Doing pre and post-production testing gives you a full spectrum of API quality and reliability throughout its life cycle.

Having the right tools to implement these testing strategies is important. Luckily, many tools are available to cover all aspects of API testing, from unit testing to security testing. Let’s take a look at some of the top tools next.

Top API Testing Tools

In this blog, we’ve talked about how vital API testing is and the benefits of using automated tools to implement it. In this section, we will look at some of the top tools for testing various aspects of APIs. Let’s take a look at some of the top tools that developers and testers should add to their testing stack.

StackHawk

StackHawk is a Dynamic Application Security Testing (DAST) tool that finds vulnerabilities in running applications, including APIs. It supports testing APIs by crawling API routes or using OpenAPI specifications. It also has built-in API discovery tools to help you find and test all your endpoints. StackHawk can be added directly into CI/CD flows to test REST APIs as developers commit their code, revealing potential security vulnerabilities in real time.

Postman

Most developers are familiar with Postman and its role in API development and testing. Postman is a versatile and widely used API testing tool that simplifies the entire API development life cycle. It allows you to send requests, test and debug responses, automate tests, document your APIs, and even monitor their performance. Its user-friendly interface and wide range of features make it a favorite among developers and testers.

SoapUI

A mainstay for developers for many years, SoapUI is an open-source API testing tool known for its extensive capabilities in testing SOAP (simple object access protocol), REST, and web services. It has a rich set of features for functional testing, security testing, load testing, and test automation. SoapUI is flexible and extensible and can be used for various API testing scenarios.

Apigee

Apigee, now part of Google Cloud, is an API management platform that can also help test APIs at various stages of development. With Apigee, you can design, secure, publish, analyze, and monitor your APIs. It supports multiple API protocols, including REST, SOAP, and GraphQL, and is a full-stack solution for managing and testing your API ecosystem.

Integrate.io

Integrate.io is a data integration platform with a RESTful API connector that simplifies integrating REST APIs into your data pipelines. Its drag-and-drop interface and prebuilt connectors make it easy to connect, transform, and load data from various sources, including REST APIs. As a platform with API management capabilities, integrate.io can help with various facets of API testing.

Swagger UI

Swagger UI is part of the Swagger (now OpenAPI) ecosystem and is an interactive API documentation tool. It also allows API users to visualize and interact with API resources without writing any logic by allowing them to test APIs with a click of a button using sample REST API request examples. In addition to the obvious benefit of interactive API documentation, Swagger UI is useful during development and testing to understand the API structure and functionality.

REST-assured

For those creating APIs in Java, REST-assured is a Java library for testing RESTful APIs. Its domain-specific language (DSL) simplifies creating test cases and validating API responses. REST-assured’s syntax and assertions are intuitive and popular among Java developers. The tool can invoke RESTful APIs and validate the requests and responses based on requirements.

With an abundance of tools available, how do you determine what tool is best for your specific use case? In the next section, we will discuss the factors to consider when evaluating API testing tools and choosing the right one for your needs.

API Testing Tools Evaluation

When choosing which tools are best for your API testing stack, there are quite a few aspects to consider. Let’s take a look at some key considerations, features, and benefits that you should consider when evaluating the tools you are evaluating.

Considerations

Functionality: Does the tool support the types of API tests you need it for(e.g. functional, performance, security)? Does it have features like test automation, data-driven testing, or integration with your CI/CD pipeline?
Ease of Use: Is the tool’s interface user-friendly? Can your team learn and adopt it without extensive training?
Scalability: Can the tool handle the volume and complexity of your APIs? Will it scale as your API portfolio grows?
Security: Does the tool have built-in security features to protect your APIs and data during testing?
Cost: Is the tool’s pricing model within your budget? Consider both upfront costs and ongoing costs like licensing or subscriptions.
Compatibility: Is the tool compatible with your existing technology stack, programming languages, and development environment?

Tool Features and Benefits

Besides the above, here are some additional features and benefits that you should look for in any tools that you adopt.

Automated Testing: Support for automating test cases saves time, improves efficiency, and allows continuous testing.
API Design and Documentation: Some tools have features for designing, documenting, and generating API specifications to promote consistency and collaboration.
Security Testing: Look for tools to help you find security vulnerabilities and risks in your APIs.
Reporting and Analytics: Robust reporting and analytics give you valuable insights into test results, allowing you to track progress, identify bottlenecks, and make data-driven decisions.
Collaboration: If you have a team of testers and developers, consider tools that support collaboration, version control, and knowledge sharing.

By evaluating these factors and considering your organization and project needs, you can choose the right API testing tools to support your testing goals and deliver high-quality, reliable, and secure REST APIs.

API Testing Best Practices

When it comes to testing best practices, each type of testing will come with its own guidelines. However, two best practices apply to all kinds of API testing: creating good test cases and automating testing through CI/CD. Let’s explore these in more detail.

Creating Effective Test Cases

Effective RESTful API testing hinges on well-crafted test cases. To achieve comprehensive coverage, a REST API test should consider both expected (positive) and unexpected (negative) behaviors, including edge cases and boundary conditions. Stress-test the API's resilience using data-driven testing with diverse input sets. Prioritize tests that target critical functionalities, potential security vulnerabilities, and performance bottlenecks. Lastly, maintain thorough documentation of test case purpose, steps, expected results, and dependencies for seamless collaboration and maintenance.

Integrating API Testing into CI/CD Pipelines

Integrating API testing into your CI/CD pipeline is critical for continuous quality assurance. Automate your tests to save time, ensure consistency, and enable frequent execution. This practice provides immediate feedback on code changes, allowing developers to quickly identify and resolve issues before making their way onto production servers. By establishing a fast feedback loop through automated testing in your CI/CD pipeline, you can proactively maintain your APIs' quality, reliability, and security.

By following these two best practices across all types of testing, you can build a solid API testing framework for your REST APIs. It’s also essential to research best practices for each specific type of API testing you implement.

Using StackHawk For REST API Testing

With security being a top priority for REST APIs, StackHawk is an excellent choice for testing APIs for vulnerabilities in the OWASP API Top 10 and beyond. Its automated testing, CI/CD integration, and developer-friendly approach align it well with many of the considerations and best practices to look for in an API testing tool. With its modern approach to DAST, it’s an invaluable tool for identifying and mitigating security risks that can impact APIs. Here are a few highlights:

Automated Security Testing Through CI/CD

StackHawk automates testing your APIs for a wide range of vulnerabilities, including those outlined in the OWASP API Top 10. This saves you time and ensures consistent security checks throughout your development cycle. By integrating with your CI/CD pipeline, StackHawk allows you to catch security issues early in the development process on every pull request. This shift-left approach empowers developers to identify and fix vulnerabilities before they reach production, reducing the risk and cost of remediation.

Comprehensive API-Specific Vulnerability Testing

Unlike other DAST solutions that struggle to thoroughly test APIs, StackHawk’s API testing capabilities identify issues like injection attacks, broken authentication, sensitive data exposure, etc. With API discovery capabilities built directly into the platform, ensure even undocumented and shadow APIs are covered. Once a test run is completed, stackHawk provides detailed vulnerability and test reports with actionable insights to help developers prioritize and fix vulnerabilities.

Customizable

StackHawk allows you to tailor its scans to your specific needs. You can configure it to focus on specific vulnerabilities, exclude certain paths, and even create custom test scripts to address unique security concerns. For paths requiring various user authentication and authorization settings, you can use StackHawk’s authenticated scanning capabilities to ensure all API routes and logic paths are included by test coverage.

Want to experience the benefits of StackHawk’s API testing capabilities for yourself? Sign up for a free trial today.

Conclusion

API testing is necessary to ensure your APIs are functional, reliable, secure, and performant. In this post, we looked at the importance of API testing, the types of tests, the challenges, and the best practices for delivering high-quality APIs. Choosing the right tools and approach is the key to implementing a comprehensive API testing strategy. You can fully capitalize on the benefits by implementing various types of API testing early, often, and in an automated manner. It's never too early in the SDLC to start testing your RESTful APIs.

As part of a holistic testing strategy, try StackHawk to experience how modern DAST can augment API security testing. Sign up today for a free trial and begin testing your APIs for the OWASP API Top 10 within minutes.

Single Page Application Security Testing: Is Scanning Your SPA with DAST Wrong?

April Conger and Eric Potter

Single-page applications (SPAs) have become the norm due to their dynamic and responsive nature. These entirely client-side GUI applications run in a desktop browser, and communicate with APIs to interact with data. But if they are client-side, why do we point our dynamic application security test (DAST) scanners at them to scan single-page applications? Aren’t the server-side APIs our real target? Learn why SPA scanning is fundamentally flawed and how to dynamically test your APIs directly for fast, accurate results with thorough coverage of your real attack surface.

The Evolution of Web Applications

In the early days of web development, traditional web apps were typically server-rendered. Technologies like Ruby on Rails, PHP, or Java would render the entire web page on the server and send the fully formed HTML to the browser. This made it straightforward for traditional DAST scanners to crawl and test the entire application.

With the advent of modern web apps, which often utilize single-page applications (SPAs), the approach has shifted significantly. SPAs enhance user experience by loading content dynamically on a single HTML page, improving load times and performance. This approach has become prevalent since the early 2010s, emphasizing the efficiency and speed advantages it provides.

These scanners, despite being slow and sometimes taking hours or days to complete, were capable of providing adequate coverage because they were designed for these server-rendered applications. They could navigate through the static HTML and simulate user interactions effectively.

The Rise of Single Page Applications

Modern web architectures, however, have shifted towards single-page applications (SPAs), where the browser’s Javascript runtime engine runs a full-fledged client-side application typically using a framework such as React, Angular, or Ember.js. There are many similar frameworks, but if your application is using any of these, it’s a good sign there’s an SPA architecture. SPAs dynamically render content and communicate with backend APIs for data. Those APIs are the true target of DAST scanning, not the SPA. This client-side rendering poses a significant challenge for traditional DAST scanners.

In a SPA, there is no static HTML to crawl. Instead, the browser-based application dynamically generates HTML using JavaScript, which means the scanner needs to execute JavaScript to fully load and interact with the application. This is where traditional scanners fall short. They attempt to render the SPA and simulate user interactions in order to reach and crawl the APIs. It never works! The SPA is changing the Document Object Model (DOM) in browser space on the fly as the scanner attempts to read and interpret it. Sometimes, the SPA intentionally hides routes in order to confuse web discovery tools, and sometimes, it happens by accident because the app is changing memory as the crawler tries to read it. It’s always a process with no defined endpoint (see CS halting problem). Ultimately, this method of crawling APIs is slow, error-prone, and typically finds less than 10% of the API attack surface.

To address these challenges, SPA security testing is crucial. It involves specialized methods to identify and mitigate vulnerabilities in SPAs, focusing on the dynamic nature of their content and the security of their underlying APIs.

Understanding Single Page Applications and Security Testing

Single-page applications (SPAs) have revolutionized modern web development by offering a seamless and interactive user experience. Unlike traditional web applications that require a full page reload for every user interaction, SPAs dynamically update their content in real time. This is achieved through the use of JavaScript and APIs, which fetch data from the server and update the web page without disrupting the user experience. However, this dynamic nature also introduces new security challenges that must be addressed through effective security testing.

Security testing for SPAs is crucial to identify potential security vulnerabilities that could compromise the application and its users. Traditional security testing methods, such as crawling frontend URLs and using spiders, fall short when dealing with SPAs due to their dynamic nature. Instead, a more comprehensive approach is required, including API security testing, client-side scripting analysis, and user interaction simulation. This ensures that all potential security vulnerabilities are identified and addressed, safeguarding the integrity of the application and the sensitive data it handles.

Challenges of Security Testing for SPAs

Security testing for SPAs presents several unique challenges due to their architecture and behavior. One of the primary challenges is the dynamic nature of SPAs, which makes it difficult for traditional security testing tools to effectively crawl and analyze the application. SPAs rely heavily on client-side scripting, which can introduce security vulnerabilities if not properly validated. Additionally, SPAs often use APIs to fetch data from the server, which can also pose security risks if not adequately secured.

The complexity of SPAs further complicates security testing. These applications often consist of multiple components and libraries, each of which can introduce security risks if not properly configured. Moreover, SPAs are typically developed using modern web development frameworks and libraries, which can introduce new security risks if not thoroughly understood. Identifying and prioritizing security vulnerabilities in such a complex environment requires a specialized approach that goes beyond traditional security testing methods.

The Limitations of Traditional Scanners

When a traditional DAST scanner tries to scan SPAs, it faces several limitations:

Poor API Coverage: SPAs interact heavily with backend APIs. Traditional scanners are not designed to understand and fully explore these API endpoints. They might hit a few paths but will miss most, resulting in poor coverage. In addition, an API endpoint call discovered via the SPA might not reveal all of the endpoint’s capabilities or payload options, again resulting in incomplete coverage.
Slow Performance: Attempting to render and interact with a dynamic SPA in a simulated browser environment is extremely slow. This often results in even longer scan times than for traditional server-rendered applications. Furthermore, as mentioned above, the changing nature of a SPA while being crawled invokes the halting problem, wherein, it’s impossible for a crawler to identify when it’s “done”. Frequently, the SPA crawler has to be limited by a timer, giving it a “best-effort” deadline.
Incomplete Results: The consolidated scan results from a traditional scanner provide limited insights into where vulnerabilities lie within the SPA, making it harder to identify root causes and fix issues.

The Importance of API Security Testing

API security testing is a critical component of security testing for SPAs. Since SPAs rely heavily on APIs to fetch data from the server, ensuring that these APIs are properly secured is essential. API security testing involves analyzing the API endpoints, input validation, authentication mechanisms, and data handling practices to identify potential security vulnerabilities.

Through API security testing, organizations can identify vulnerabilities such as cross-site scripting (XSS), cross-site request forgery (CSRF), and SQL injection. It also helps in identifying security risks associated with sensitive data, such as user credentials and personal information. By addressing these vulnerabilities, organizations can ensure the security and integrity of their SPAs, protecting their users’ sensitive data and maintaining trust in their web applications.

A Better Approach with StackHawk Security Testing Tool

StackHawk addresses these challenges by focusing on direct API testing rather than trying to scan through the SPA to find the API. Here's how StackHawk makes a difference:

Local Scanning: By coming in behind the firewall, StackHawk can test each API domain and endpoint locally, leading to much faster scan times.
Comprehensive API Coverage: Using API specifications or engineering-developed test suites such as Postman Collections, StackHawk can crawl and test every single route and input parameter available in an API, ensuring 100% coverage.
Detailed and Actionable Results: StackHawk provides detailed insights into vulnerabilities within each API, making it easier to pinpoint and resolve issues.

Bridging the Gap Between Security and Development

One of the key takeaways from using StackHawk is the realization among security professionals that they need to collaborate more closely with developers to accomplish meaningful security testing. Without the expertise of the application developers, most attempts at security testing become a variant of closed-box testing with the expected poor results. Discussions about OpenAPI specifications or other engineering artifacts often lead to the conclusion that involving developers in the security testing process is a win-win-win. Developers learn about the importance of secure coding and get rapid feedback on secure code improvements, accelerating the find-fix cycle. Security gets faster, higher-quality testing results and can move away from the eternal ticketing of issues to focus on higher-level organizational issues. The organization wins across the board by enabling faster and more secure feature delivery. The security-engineering collaboration ensures that security is integrated into the development lifecycle early and often during the SDLC, leading to more secure applications at a lower cost and faster time-to-market. Understanding how users interact with the application is crucial for effective security testing, as it helps identify potential vulnerabilities and enhances the overall functionality of the application.

Testing SPAs and other modern web apps with traditional DAST scanners is a futile effort that results in poor coverage, slow performance, and incomplete results. StackHawk offers a more effective solution by focusing on API testing, providing comprehensive coverage, faster scan times, and detailed insights. This approach not only improves security testing but also fosters better collaboration between security teams and developers. If you’re still scanning your front-end apps using traditional scanners, it’s time to rethink your strategy and consider StackHawk for a more effective and efficient security testing process. Visit StackHawk to learn more, or signup for a free trial here.

Embracing the Future of Security with the Shift-Left Maturity Model

Joni Klippert

When it comes to building software, speed is king. Getting to market quickly is usually a top priority for most organizations, and rightly so. But too often, security is treated as an afterthought in the software development life cycle, a hurdle to jump over at the last minute. This approach is risky and creates a frustrating bottleneck for everyone involved in the development cycle.

The good news is that there's a better way. By shifting security “left” through "shift-left" testing and other means and integrating it into the early stages of development, we can build more secure products faster and with less hassle. With the Shift-Left Maturity Model, you have a clear roadmap to make this happen. At the core of this model are three foundational elements: people, process, and tooling. Empowering your team with the right skills and mindset is crucial for fostering a security-first culture. Establishing robust processes that integrate security seamlessly from the outset ensures consistency and efficiency. Leveraging advanced tools that automate and streamline security tasks makes it feasible to maintain speed without compromising on security. Together, these elements form the backbone of the Shift-Left Maturity Model, guiding organizations to achieve both rapid delivery and robust security in their software development practices.

Understanding the Shift-Left Maturity Model

The Shift-Left Maturity Model isn't just a fancy term – it's a practical framework designed to guide organizations through the evolution of their security practices. It categorizes the journey into four stages, helping you advance your security posture. In every stage, the model has three key elements: people, process, and tooling. These elements form the backbone of the model, helping organizations achieve fast and secure software development. The model itself outlines a structured path to advance an organization's security posture and security measures. Let’s explore the four distinct stages:

1. Box Checking Basics

This is where many organizations start. You're focused on meeting basic compliance requirements, often relying on manual processes and periodic audits. It's a start, but it leaves you vulnerable and reactive. Let’s briefly look at a few characteristics and challenges of this stage.

Characteristics:

Security is seen as a separate function.
Limited integration of security tools in the CI/CD pipeline.
Reliance on manual processes and external audits.
Minimal developer involvement in security practices.

Challenges:

Slow response to emerging threats.
Security silos create bottlenecks.
Higher costs due to late-stage defect detection.

2. Shift-Left Curious

Here, you're beginning to see the value of early security integration. You're exploring automated tools and building collaboration between security and development teams. You’ll start to see improvements in the security of your applications. However, you still could dig in more to experience even further benefits from fully committing to the “shift-left” approach. Here are a few of the characteristics and challenges of this stage.

Characteristics:

Introduction of automated static and dynamic analysis tools.
Initial efforts to embed security testing in CI/CD pipelines.
Growing awareness and training for developers on secure coding practices.

Challenges:

Inconsistent tool adoption and integration.
Cultural resistance to change.
Need for more sophisticated tooling and processes.

3. Shift-Left Committed

Now, security is a core part of your development process. You've fully embraced DevSecOps, a methodology that seamlessly weaves security practices into every phase of the software development lifecycle. Automated security tools are integrated throughout your workflow, from code creation to deployment. Security is no longer the sole responsibility of a siloed team; it's a shared responsibility that everyone on the development team takes seriously. The characteristics and challenges of this stage include:

Characteristics:

Comprehensive integration of security tools in CI/CD pipelines.
Continuous monitoring and real-time threat detection.
Regular security training and awareness programs for all team members.
A collaborative environment where security is everyone’s responsibility.

Challenges:

Balancing speed and security without compromising either.
Ensuring scalability of security practices.
Maintaining a high level of security awareness and skill among all team members.

4. Continuously Secure

This is the pinnacle of the Shift-Left Maturity Model, the ultimate goal of seamlessly interweaving security into the very fabric of your organization. It's not just about checking boxes or even integrating tools; it's about creating a security-centric culture where everyone understands the importance of security and actively contributes to maintaining a strong security posture. Once you’ve come into this stage, you’ll see the following characteristics and challenges appear:

Characteristics:

Proactive threat modeling and risk management.
Business-driven security metrics and KPIs.
Advanced automation and AI-driven security solutions.
A strong security culture is embedded in the organization’s DNA.

Challenges:

Continuous adaptation to evolving threat landscapes.
Integrating advanced technologies without disrupting existing processes.
Sustaining a culture of continuous improvement and vigilance.

The Journey Towards Secure Business Outcomes

Embarking on the journey towards secure business outcomes isn't a sprint; it's a strategic evolution that requires a multi-faceted approach. It demands a commitment to continuous learning, a willingness to adapt, and a dedication to fostering a culture of security within your organization. Here's how you can navigate this transformative path:

Know Your Starting Point

Before plotting your course, you need to understand where you currently stand. Take a comprehensive inventory of your existing security practices, tools, and processes. Don't shy away from identifying gaps or areas for improvement. This assessment will serve as your foundation for building a more robust security posture.

Set Your Sights on Success

Define clear, achievable goals for each stage of the Shift-Left Maturity Model. These goals should not exist in a vacuum; they need to be aligned with your organization's broader business objectives. This ensures that your security initiatives are strengthening your defenses and driving business value.

Empower Your Team Through Knowledge

Your team is your greatest asset in the quest for security excellence. Equip them with the knowledge and skills to embrace new security practices. Regular training sessions, workshops, and awareness programs are essential for keeping everyone up-to-date on the latest threats and best practices.

Harness the Power of Automation

Don't let your team get bogged down by repetitive, manual security tasks. Invest in automated security tools that seamlessly integrate with your development workflows, including continuous integration. Automation frees up valuable time and resources and ensures consistent and reliable security checks throughout the development process. A good place to start is looking at tools like Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Dynamic Application Security Testing (DAST) platforms to enable automated software testing.

Build Bridges, Not Walls

Break down the silos that often separate development, security, and operations teams. Foster a culture of collaboration and open communication where everyone feels a shared responsibility for security. When these teams work together as a cohesive unit, you'll be far more effective at identifying and addressing security risks.

Measure Your Progress and Adapt

The journey to secure business outcomes is ongoing. Continuously monitor your progress, measure the effectiveness of your security practices, and be prepared to adapt your approach as needed. Use data-driven insights and feedback from your team to drive continuous improvement.

By following these steps and embracing the principles of the Shift-Left Maturity Model, you can transform your organization into a security powerhouse. By building a reputation for trustworthiness and reliability, you'll protect your valuable assets and gain a competitive edge.

Conclusion

The path to secure business outcomes is not always easy, but it's a journey well worth taking. By embracing the Shift-Left Maturity Model, you're not just mitigating risks; you're fostering a culture of innovation, collaboration, and resilience. By implementing shift-left security, you're building a future where security isn't an obstacle but a catalyst for growth and success.

Remember, this isn't about achieving perfection overnight. It's about progress, continuous improvement, and a commitment to making shift-left security a core part of your organization's DNA.

Ready to embark on this journey? Download our comprehensive guide on the Shift-Left Maturity Model and start transforming your security practices today. Let us be your trusted partner as you navigate this exciting evolution and unlock the full potential of secure business outcomes. For more information on how to automate security using StackHawk and Dynamic Application Security Testing (DAST), visit us here.

StackHawk Announces HawkScan Test Engine

Scott Gerlach

We are excited to announce that with the release of HawkScan 4.0, the transition to the HawkScan Test Engine (HSTE) will be complete. HSTE is the foundation of our scanning technology, embodying all of the enhancements and improvements StackHawk has developed to the Dynamic Application Security Testing capability. This move not only reinforces our commitment to providing top-tier security testing tools but also ensures that our customers benefit from faster updates and more robust features tailored to their needs.

The decision to fork ZAP was driven by the need for a development process that could keep pace with the rapid innovation demanded by StackHawk’s users. By forking ZAP, StackHawk has created a more agile and responsive development environment that aligns more closely with its strategic goals and customer requirements, including much deeper investment in API Security Testing.

Over time, the development work required to support StackHawk customers required a great deal of custom development for core functionality, speed, innovation, and also custom tests (what we test) as well as testing capabilities (how we test) to address web 3.0 and API driven development. This internal fork allows StackHawk to rework, remove and replace ZAP’s internals, making it easier to develop and support new features, ultimately accelerating time-to-market for enhancements critical to StackHawk's customer base. We remain grateful to the ZAP community and are committed to contributing to the open-source ecosystem in meaningful ways.

How We Built HawkAI to Protect Your Data

Scott Gerlach

We’re thrilled to offer customers the power of AI to maximize efficiency, and protecting customer data will always be our top priority. Our AI technology, HawkAI, conducts a non-intrusive analysis of your code repositories, ensuring your source code remains private and secure.

HawkAI prioritizes data privacy by adhering to strict principles:

No source code, sensitive data, or PII data is shared with third parties.
No LLM Training: We don't use your data to train large language models.
Code Integrity: HawkAI does not send code contents to 3rd parties.

This ensures a powerful and secure experience you can trust. Read on to learn how each principle works in practice.

How does the AI feature work on a technical level?

StackHawk leverages AI to perform non-intrusive analysis of your code repositories, focusing on identifying programming languages, code frameworks, and other indicators of testable applications or APIs. This process is done without storing any of your source code, ensuring the privacy and security of your data. Additionally, your source code is never shared with third parties, maintaining strict confidentiality.

Where are we sending the data?

The data processed by HawkAI is handled internally within StackHawk's secure systems and with our selected AI vendor to ensure the confidentiality and security of your information. Our AI vendors undergo StackHawk’s vendor security review and onboarding process detailed in our Third-Party Management Policy. No source code, sensitive data, or PII data is shared with third parties, aligning with StackHawk's data privacy and security commitment.

What type of data will be processed by the API?

HawkAI focuses on interpreting the organizational patterns within your repositories to determine what kinds of applications or APIs are present, using this information as the source of truth. This process is conducted without storing any source code, ensuring the integrity and confidentiality of your data. PII data is never used in the HawkAI process.

Will the data be used for training?

Although StackHawk utilizes AI to analyze code repositories, the data processed by HawkAI will never be used to train large language models. The primary objective is to identify applications and APIs, with a commitment to keeping your source code private and not using it for training purposes.

Which AI provider are you leveraging?

StackHawk currently utilizes OpenAI, but our system is designed to be adaptable, allowing the integration of other large language models as needed. This flexibility ensures we continuously evaluate and implement the most effective AI solutions based on research and testing to enhance our functionality.

Can I opt out of AI usage?

Yes, HawkAI is enabled by default only through the GitHub integration. If you would like to utilize other GitHub integration features without allowing AI access, read the docs for instructions on how to disable HawkAI on your account.

Defending Against API Attacks: Strategies for Protecting Your APIs and Data

StackHawk

APIs (Application Programming Interfaces) are the hub of functionality in modern software, enabling communication and data exchange between applications and delivering almost all of an application's capabilities. With APIs being so critical, it's no surprise that this connectivity makes them a prime target for attackers seeking to exploit vulnerabilities and gain unauthorized access. Bad actors constantly develop new techniques to bypass API security measures, compromise sensitive data, or disrupt operations.

Common API attack types and vectors include injection attacks, cross-site scripting (XSS), denial-of-service (DoS), and authentication bypasses. Each uses different approaches. Injection attacks involve inserting malicious code into API requests, while XSS exploits inject malicious scripts into web pages viewed by other users. DoS attacks aim to overwhelm an API with traffic, rendering it inaccessible, and authentication bypasses seek to gain unauthorized access to restricted resources.

This blog will examine these attack vectors and the specific techniques attackers employ. More importantly, we will explore a multi-layered defense strategy that combines strong authentication, rate limiting, secure session management, input validation, and encryption. We will also examine how security testing can ensure that your defense strategy is robust and working as intended. By understanding the threat landscape and implementing these API security best practices, you can fortify your APIs against attacks and ensure your data's confidentiality, integrity, and availability.

Understanding API Attacks

API (Application Programming Interface) attacks are a serious and escalating threat as APIs become more widely used and handle increasingly important tasks. These unauthorized attempts to access or manipulate APIs can result in significant data breaches, system disruptions, and financial losses for organizations. In recent years, there has been a surge in API attacks, particularly targeting critical sectors like healthcare, finance, and government.

Defending against API attacks is increasingly challenging due to the dynamic nature of APIs and the constant introduction of new API technologies. DevOps's rapid pace and traditional network security limitations often leave organizations vulnerable to API attacks. Attackers exploit these weaknesses by carefully studying API implementations and structures, probing for vulnerabilities, and devising attack strategies to overcome any security that may or may not be implemented on the endpoint.

To effectively protect your APIs, it's crucial to understand the anatomy of these attacks and the potential weaknesses in your API security. By understanding the threat landscape and creating your API security checklist, you can proactively implement security measures to safeguard your APIs and the data that flows through them.

Anatomy of Common API Attacks

API attacks encompass various tactics designed to exploit vulnerabilities and achieve malicious objectives. They can range from stealing credentials to manipulating business logic or exploiting technical weaknesses. Understanding the anatomy of these attacks and how attackers exploit vulnerabilities is essential to developing effective defenses and usually involves protecting APIs from multiple angles. Let's look at a few of the most common attacks occurring within APIs.

Injection Attacks: SQL Injection and Cross-Site Scripting (XSS)

API injection attacks, such as SQL injection (SQLi) and cross-site scripting (XSS), are among the most common and dangerous API threats. SQL injection attacks insert malicious SQL queries into input fields to manipulate or extract data from the underlying database. On the other hand, XSS injects malicious scripts into web pages viewed by other users, potentially compromising their interactions with the application.

These attacks often exploit inadequate input validation mechanisms, allowing attackers to introduce harmful code into the system. To ensure these attacks cannot transpire, robust input validation is a crucial defense against injection attacks, ensuring all data is thoroughly sanitized and checked before processing within the API's logic.

Denial of Service (DoS) and Distributed Denial of Service (DDoS)

Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks aim to disrupt the availability of an API by overwhelming it with a flood of requests. DoS attacks typically originate from a single source, while DDoS attacks leverage multiple compromised machines to amplify the impact.

One of the main ways to prevent this is to introduce rate limiting to the API endpoint. Rate limiting is an effective defense against DoS and DDoS attacks since it controls the flow of traffic to the API, preventing it from being overwhelmed. Additionally, implementing anomaly monitoring detection and using CAPTCHAs can help mitigate automated threats.

Authentication Flaws and Session Token Hijacking

Authentication flaws are vulnerabilities in the authentication process that allow attackers to gain access to APIs through broken access control mechanisms. These flaws can stem from stolen credentials, weak password policies, insecure session management, or credential-stuffing attacks. In some cases, attackers can hijack valid session tokens to impersonate legitimate users, gaining unauthorized access. Attackers can also intercept the session token issuing API through a Man in the Middle (MITM) attack to gain access to a user's account and potentially compromise sensitive information.

Strong authentication mechanisms, such as multi-factor authentication (MFA) and secure session management, prevent unauthorized access. MFA adds an extra layer of security by requiring users to provide multiple verification forms, while secure session management ensures that session tokens are properly generated, stored, and validated.

These common API attacks are well-documented, and many ways exist to test and protect against them. The best approach to prevent API attacks is to be proactive and ensure they don’t take down or exploit an API. The next section will explore how to protect against these exploits proactively.

Proactive Measures for API Security

Proactive API security involves implementing measures to defend against attacks and actively identify and mitigate potential threats. This multi-layered approach is crucial in preventing and detecting API attacks before and if they occur.

Rate Limiting and Strong Authentication

Rate limiting and strong authentication mechanisms are fundamental components of proactive API security. Rate limiting acts as a traffic controller, restricting the number of requests an API can handle within a given timeframe from a specific user, usually controlled through API keys. This effectively mitigates the risk of denial-of-service (DoS) attacks and other automated threats since it prohibits massive spikes in traffic.

Additionally, Strong authentication mechanisms, such as multi-factor authentication (MFA), provide an additional layer of security by requiring users to verify their identity through multiple channels. Unlike UI-based MFA, API-based MFA may require users to supply multiple credentials, such as an API key and a client secret. This two-factor authentication significantly reduces the risk of unauthorized access, even if credentials are compromised.

Encryption and Secure Data Transfers

Encryption is critical to data security, ensuring that sensitive information remains confidential during transmission and once stored. Protocols like Secure Sockets Layer (SSL) and Transport Layer Security (TLS) encrypt data in transit, protecting it from eavesdropping and tampering. Most databases have built-in functionality that allows users to automatically encrypt the data at rest once stored on the database.

Encryption is critical for safeguarding sensitive and personal information in the context of APIs. Encrypting API traffic can effectively neutralize man-in-the-middle attacks and other attempts to intercept or modify data.

Regular Security Assessments and Input Validation

Regular security assessments are essential for identifying and addressing vulnerabilities in your API infrastructure. These assessments should be conducted by experienced security professionals who can thoroughly examine your APIs, pinpoint weaknesses, and recommend appropriate remediation measures. To go even further, implementing automated solutions, such as Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST), is also a great way to catch security defects before they have a chance to hit production servers.

Input validation is another critical defense mechanism. It involves rigorously checking all input data to ensure it conforms to expected formats and does not contain malicious code. This is crucial for preventing injection attacks like SQLi and XSS, which often exploit poorly validated input fields. Many automated testing solutions will also check for these types of vulnerabilities.

By proactively implementing these security measures, you can create a robust security strategy that significantly reduces the risk of API attacks. This continuous process requires vigilance, adaptation, and investment in the latest security technologies, tools, and practices.

Mitigating API Security Vulnerabilities

Mitigating API security vulnerabilities requires a proactive and adaptive approach. This is required since you want to mitigate exploits before they happen and exploits always evolve. In addition to the proactive steps mentioned above, there are some other strategies you can implement to keep your APIs secure. Let's take a look at a few areas to improve API security.

Zero Trust Architecture and API Asset Management

Adopting a zero-trust architecture means assuming that no user or device can be inherently trusted. This approach requires continuous authentication and authorization for every request, regardless of origin. Comprehensive API asset management involves maintaining an inventory of all APIs, their versions, and their associated security configurations. API discovery and cataloging tools can help to stay on top of this requirement.

Automated API Documentation and Security Firewalls

Automated API documentation tools can help streamline the process of documenting API specifications, security policies, and usage guidelines. This documentation is crucial for developers, security teams, and API consumers to understand and adhere to security best practices. API security firewalls provide additional protection by filtering traffic and blocking malicious requests based on predefined rules, generally documented within the API docs. These firewalls can help prevent attacks like SQL injection, cross-site scripting, and unauthorized access.

Access Control and Usage Policies

Implementing robust access control policies is essential for preventing unauthorized access to APIs. API gateways are central control points, enforcing authentication and authorization rules. A fine-grained access control policy allows you to define permissions at a granular level, ensuring that users can only access the specific resources and actions they are authorized to use.

Usage policies define the acceptable use of APIs, including rate limits, quotas, and restrictions on specific actions. Enforcing these policies through the usage of an API gateway or other mechanisms can prevent abuse and ensure fair access to your APIs.

Monitoring and Logging

Continuous monitoring and logging of API activity are crucial for detecting and responding to security incidents. Insufficient logging makes detecting and understanding what happened during an API attack harder. By collecting and analyzing API logs, you can identify suspicious patterns, unauthorized access attempts, and potential vulnerabilities. You can see attacks as they happen by including real-time monitoring, allowing immediate response, and minimizing the impact.

Effective logging practices include capturing detailed information about API requests and responses, including timestamps, user IDs, IP addresses, and error codes. This descriptive information around every piece of the API call is invaluable for analysis and incident response.

Error Handling and Response Strategies

Proper error handling is essential for both security and user experience. API errors should be handled gracefully, providing clear and informative error messages to API consumers. Consistent error response formats help developers troubleshoot and resolve issues more efficiently.

Even though descriptive errors are best for user experience, error responses should not leak sensitive information, such as stack traces or database details. Instead, they should provide generic error codes and messages that help users understand the nature of the problem without compromising security. Additionally, implementing retry mechanisms and fallback strategies can help mitigate the impact of temporary errors and improve the resilience of your APIs.

Implementing these comprehensive security measures and combining the others we have discussed will help to secure your APIs sufficiently. To fully understand the impact of foregoing these security measures, let's examine some real-world incidents.

Case Studies: Lessons from Real-World API Attacks

Examining real-world API attacks provides valuable insights into the tactics attackers employ and the vulnerabilities they exploit. These case studies serve as cautionary tales, highlighting the importance of robust API security practices.

Instagram API Breach: The Danger of Exposed Personal Information

In 2019, a vulnerability in Instagram's API allowed attackers to access the personal information of high-profile users, including phone numbers and email addresses. This breach exposed a critical weakness in the API's authentication and authorization mechanisms, enabling attackers to bypass security measures and retrieve sensitive data without proper authorization.

Lessons Learned:

Strong Authentication is Critical: Implement multi-factor authentication (MFA) and strict authorization controls to prevent unauthorized access to sensitive data.
Regular Security Assessments: Conduct routine security assessments to identify and address vulnerabilities before they can be exploited by attackers.
Data Minimization: Only collect and store the minimum amount of user data necessary to fulfill the API's intended purpose and minimize excessive data exposure.

Snapchat API Breach: Exploiting Insecure Direct Object References

In 2013, Snapchat suffered a major security breach due to insecure direct object references (IDOR) in its API. This vulnerability allowed attackers to bypass API server protections and directly access user data, including usernames and phone numbers, by manipulating the parameters in API requests.

Lessons Learned:

Input Validation is Crucial: Validate all user input to prevent injection attacks like IDOR, which can allow attackers to access unauthorized resources.
Defense in Depth: Implement multiple layers of security, including input validation, access controls, and rate limiting, to create a robust defense against attacks.

Uber Data Breach: The Cost of Inadequate Security

In 2016, Uber experienced a data breach that exposed the personal information of 57 million users and drivers. The attackers accessed sensitive data stored on a third-party cloud service by exploiting weak authentication mechanisms and insufficient security controls.

Lessons Learned:

Secure Third-Party Services: Ensure that any third-party services that handle your data have robust security measures.
Incident Response Planning: Develop and test an incident response plan to ensure a swift and effective response in case of a breach.
Transparency and Communication: Communicate openly and transparently with users in case of a security incident, providing information about the breach and the steps being taken to mitigate its impact.

These case studies underscore the importance of proactive API security measures, such as strong authentication, input validation, access control, encryption, and regular security assessments. By learning from others' mistakes and implementing best practices, you can significantly reduce the risk of API attacks and protect your data and reputation.

Using StackHawk to Protect Against API Attacks Proactively

In the ever-evolving landscape of API security, proactively testing and identifying vulnerabilities is crucial to staying ahead of potential threats. StackHawk is a powerful API security testing platform that enables you to discover, analyze, and address vulnerabilities in your APIs before they are exploited by attackers.

Key Functionalities of StackHawk:

Comprehensive Vulnerability Scanning: StackHawk performs automated security scans of your APIs, checking for a wide range of vulnerabilities, including those mentioned in this guide (injection attacks, cross-site scripting, authentication flaws, etc.).
CI/CD Integration: Seamlessly integrate StackHawk into your existing CI/CD pipeline to automate security testing as part of your development workflow. This ensures that security checks are performed early and often, reducing the risk of vulnerabilities reaching production environments.
Prioritized Findings: StackHawk prioritizes identified vulnerabilities based on their severity and potential impact, helping you focus your remediation efforts on the most critical issues.
Detailed Remediation Guidance: StackHawk provides actionable remediation guidance for each identified vulnerability, making it easier for developers to understand and fix the issues.

Introducing StackHawk's API Discovery Feature (Powered by HawkAI)

A significant challenge in API security is discovering and understanding all the APIs within your environment. StackHawk's API Discovery feature, powered by HawkAI, addresses this challenge by automatically identifying and documenting your APIs.

HawkAI: Leveraging AI and source code insights, HawkAI analyzes your codebase to uncover documented and undocumented APIs. This comprehensive discovery process ensures that no API endpoint goes untested.
Enhanced Security Testing: By combining API discovery with StackHawk's robust scanning capabilities, you can ensure that all of your APIs, including those in your attack surface that may have been previously unknown or overlooked, are thoroughly tested for vulnerabilities.
Improved Collaboration: HawkAI bridges the gap between security and development teams by providing insights into the ownership and usage of APIs. This fosters collaboration and facilitates quicker remediation of vulnerabilities.

Conclusion

The importance of API security can't be understated in today's interconnected digital landscape. As APIs have become crucial in almost every modern application, they have become a popular and sometimes easy target for attackers. API attacks are a persistent and evolving threat, capable of causing significant damage to organizations through data breaches, service disruptions, and financial losses.

This guide has explored a range of proactive strategies for defending your APIs against many types of API attacks. We looked at various angles and discussed the critical role of strong authentication, rate limiting, input validation, encryption, and regular security assessments in fortifying your API infrastructure.

Understanding the anatomy of common API attacks and implementing the defense-in-depth strategies outlined in this guide can significantly reduce your organization's risk exposure and improve your security posture. Remember, API security is not a static set-and-forget component but an ongoing process that requires continuous monitoring, adaptation, and investment in the latest security technologies and practices.

When building out your API security stack, StackHawk is a critical component that allows you to validate your current API security status and proactively improve it. By using StackHawk's modern DAST approach, many of the most common API vulnerabilities can be easily detected and remedied before they have a chance to hit production. By plugging StackHawk directly into your CI/CD pipeline, testing can be automated to alert you and your team of critical API security issues introduced with every pull request. To try out StackHawk for yourself, sign up for a free trial today and test your APIs in minutes to find and fix any security flaws that could be vulnerable to an API attack.

Don't wait for a security incident to force you into reactive mode. Take proactive steps to secure your APIs and protect your valuable data assets. By prioritizing API security, you can build more resilient and secure APIs that your users can trust.

Finding and Fixing BFLA Vulnerabilities in NodeJS With StackHawk

StackHawk

For developers striving to build secure APIs, Broken Function Level Authorization (BFLA) is a crucial vulnerability demanding meticulous attention. BFLA belongs to the OWASP API Security Top 10 list and can pave the way to unauthorized access and manipulation of functionality within your API, compromising the overall integrity of your system. This occurs when applications lack adequate authorization checks focused on specific functions or features. This weakness enables attackers to manipulate calls to endpoints to which they shouldn't have access, potentially escalating access to functions reserved for higher privilege levels (like administrative actions).

Let's explore BFLA in more detail, including its nature, common root causes, and how to pinpoint BFLA vulnerabilities in your API code. Following this, we'll use StackHawk to scan a susceptible Node.js application, locate a BFLA vulnerability in one of our endpoints, and then implement the necessary fix. Finally, we'll re-scan to validate that the vulnerability has been patched. Let’s begin by digging into the foundations of BFLA vulnerabilities.

What is Broken Function Level Authorization (BFLA)?

Broken Function Level Authorization (BFLA) remains a significant risk to the security of APIs. This vulnerability surfaces when an API fails to implement robust controls, allowing users to access features and functions beyond their assigned permissions. Function-level authorization defines specific API actions that different user groups (or roles) can execute. For instance, a regular user of a banking app should not be able to perform administrative actions related to other user accounts. BFLA flaws emerge when these intended restrictions are weak or missing.

The pattern of BFLA attacks is straightforward. An attacker begins by analyzing API behavior to understand how API endpoints are named or structured. Then, they might attempt to alter HTTP methods (e.g., switch from GET to POST) or other elements in the function call requests. This is done in the hope of reaching unauthorized functionality. Weak authorization checks allow attackers to view, change, or execute commands with elevated privileges.

How Does BFLA Differ from BOLA?

You might encounter terms like "BFLA" and "BOLA" (Broken Object Level Authorization) in API security discussions. The overlap between these terms is significant, so understanding the subtle distinction is helpful. BOLA spotlights scenarios where an API directly exposes references or identifiers to internal objects, making them vulnerable to manipulation. BFLA takes a broader view, focusing on any breakdown in the logic that enforces function-level authorization within an API.

In short, BFLA is the broader category that encompasses BOLA-type issues. BFLA concerns go beyond the use of predictable IDs; they also stem from a failure to rigorously validate whether the user making a request is authorized to execute that particular API function.

What is The Root Cause of BFLA?

BFLA vulnerabilities typically stem from development practices that prioritize convenience over robust authorization. Here are several common contributing factors:

Oversimplification of Authorization: APIs that rely on basic checks without considering the full range of functions they expose are vulnerable to exploitation.
Lack of Consistent Authorization: Inconsistent or absent authorization across various API endpoints creates potential entry points for attackers.
Blind Trust in User-Supplied Data: All information users provide must be treated cautiously and validated, including parameters that might influence the functionality being accessed.
"Security Through Obscurity": Relying on hard-to-guess API paths or obscure naming conventions offers a false sense of security. Determined attackers can often bypass these.

At its core, BFLA arises from the absence of robust and function-specific authorization controls embedded directly into the API's design.

Preventing Broken Function Level Authorization (BFLA) Vulnerabilities

The key to avoiding BFLA vulnerabilities lies in adopting a comprehensive approach encompassing secure design, robust authorization, and continuous monitoring. Here are some best practices:

Enforce Rigorous Authorization Checks: Validate users' permissions with each attempted access to an API function.
Least Privilege Principle: Limit user and application access to the minimum necessary functions and data required.
Input Validation: Carefully scrutinize all input data from users, particularly values that can influence what API functions are accessed.
Regular Security Testing: Use automated security testing tools like StackHawk and employ penetration testing to uncover vulnerabilities like BLFA proactively.
Developer Education: Train your development team in secure coding practices with awareness of BFLA and similar vulnerabilities.

By following these guidelines, you'll significantly reduce your application's risk of BFLA vulnerabilities, ensuring users can only access what they're supposed to. Now, let’s put this into practice by looking at a vulnerable NodeJS application and using StackHawk to identify the BFLA vulnerability and help us verify that the fix we will implement successfully remediates the issue.

Detecting and Fixing BFLA Vulnerabilities in NodeJS

Building The Vulnerable Endpoint

Below is an example of a simple Node.js API with a BFLA vulnerability. This API allows users to delete a user based on a user ID passed in the URL. However, it doesn't perform any checks to ensure that the user making the request has the applicable role, being an “admin, before running the logic within the endpoint. This demonstrates a BFLA vulnerability in its most simple form, allowing an unauthorized user to perform a function they shouldn’t have access to.

Please note: This is an intentionally vulnerable API for demonstration purposes. Do not use this code in a real application, as it is not production-ready.

To run this app, first, ensure you have Node.js installed. Then, create a new directory for your project, ours is named “bfla-api-example”, and initialize the directory by running

npm init

You'll also need to install Express, a popular web framework for Node.js, as well as a few other dependencies we will use in the project. You’ll do this by running the following npm command:

npm install express body-parser sqlite3 express-oas-generator jsonwebtoken

Note: The jsonwebtoken dependency will be used later, but we will install it now for ease.

Now, in the root of the project we just created, create a file named app.js and add the following code:

Let's run through a quick breakdown of the updated code, which demonstrates how to create a simple web server using Node.js, Express.js, SQLite3, and automated OpenAPI documentation creation with express-oas-generator. This code provides a REST API for accessing and modifying user information stored in an SQLite database, running in memory for simplicity and demonstration purposes. Here's a detailed look at the key components and actions within the code:

1. Initialization of Express App

The code begins with initializing an Express application (`const app = express();`), the backbone for creating API endpoints.

2. Configuration for OpenAPI Documentation

The `expressOasGenerator.init(app, ...);` section is set up to generate OpenAPI documentation for the Express app automatically. This documentation dynamically adjusts based on the defined API paths.
In this initialization, the documentation for the GET method at the `/users/{id}` endpoint is explicitly modified to detail the parameters expected.
The PUT method for the /users/{id} endpoint is excluded from the OpenAPI documentation, indicating that it is intended for admin access only, thus, not publicly documented.

3. Use of Middleware

The `app.use(bodyParser.json());` configures the Express app to use `body-parser` middleware, enabling the app to parse JSON request bodies. This is essential for endpoints that accept data, such as PUT requests.

4. SQLite Database Setup

An SQLite database is initialized in memory (`const db = new sqlite3.Database(':memory:');`), making it temporary and ideal for demonstrations without external database connections.
Inside `db.serialize(...)`, a table named `users` is created, and three example user records are inserted, setting up initial data with various roles.

5. API Endpoint Definitions:

GET Endpoint: The route `app.get('/users/:id', ...)` defines an API endpoint that allows clients to fetch user data by ID. It uses a parameterized SQL query to retrieve user details, ensuring protection against SQL injection.
PUT Endpoint: The route `app.put('/users/:id', ...)` provides a means to update user details, accept JSON input for name and role, and perform an SQL update operation. This endpoint is made exclusive for specific roles by excluding it from the publicly generated API documentation. Although this endpoint is excluded from the API spec output, it doesn’t have any actual authorization in place, meaning that it is still fully accessible.

6. Server Initialization:

Finally, the application listens to incoming requests on a specified port (`const PORT = 4000;`), making the API accessible to clients. A console log message confirms the server's successful launch.

This setup provides a functional Express app with SQLite for handling simple user data operations. It illustrates how to selectively document API endpoints using OpenAPI specifications, hiding methods from the spec that shouldn’t be publicly available. That being said, there still is a gap when it comes to the actual authorization of the PUT endpoint and is where the BFLA vulnerability exists.

Running The Code

Now that our code is complete, it’s time to run the application and bring up our API. To run your API, run the following command in a terminal pointed to the root of your project:

node app.js

Once the application is up and running, you’ll notice that the PUT /user/:id endpoint allows anyone to update user data by simply specifying a user ID in the URL. This is one simple example of a BFLA vulnerability that we will need to remediate.

Detecting The Vulnerability With StackHawk and HawkScan

Now that our code is set up and our API is running, let’s get StackHawk to identify this vulnerability for us automatically. To do this, you’ll need to ensure you have a StackHawk account. If you need one, you can sign up for a trial account or log into an existing account.

If you’re logging into an existing StackHawk account, from the Applications page, you’ll click Add an App -> Create Custom App

Since we will be testing a RESTful API, on the next page, we will choose our Application Type as “API”, the API Type as “REST / OpenAPI”, and point to our OpenAPI Specification file by selecting URL Path and adding in our endpoint, /api-spec/, into the textbox. Once complete, click Next.

Enabling BFLA Detection in HawkScan

After creating the app in StackHawk, we need to do a few more steps to enable BFLA detection in StackHawk. Two ways to do this are using the "OpenAPI - Experimental" policy or customizing an existing policy. The "OpenAPI - Experimental" policy allows users to scan for the vulnerabilities outlined in the OWASP API Security Top 10.

To set HawkScan up with the "OpenAPI - Experimental" policy, you will log into StackHawk, go to the Applications screen, and click on the settings link for your application.

Next, on the Settings screen, under HawkScan Settings, click the Applied Policy dropdown and select the "OpenAPI - Experimental" policy.

At this point, you can then run HawkScan and begin detecting potential BFLA vulnerabilities. Of course, another way to do this is to simply customize an existing policy to scan for BFLA vulnerabilities. To show how this can be done, we can navigate to the same HawkScan Settings section that we looked at above. From here, we will select the "OpenAPI/REST API" policy from the Applied Policy dropdown.

Next, click the Edit Policy button right beside the dropdown.

On the next screen, under the Plugins and Tests section, click on the BFLA entry to enable HawkScan to execute tests for potential BFLA vulnerabilities.

Now, with our application set up in StackHawk, our stackhawk.xml has been added to the root of our API project, and BFLA detection has been enabled, we can finally test our application.

Run HawkScan

To test our application, in a terminal pointing to the root of our project, we will run HawkScan using the following command:

hawk scan

After running the command, the tests should execute in the terminal.

This will run tests against our API based on the OpenAPI spec using the OpenAPI Spider provided by StackHawk.

Explore The Initial Findings

Once the tests are complete, the terminal will contain some information about any vulnerabilities found. Below, we can see that it has identified the BFLA vulnerability that we introduced in the code. To explore this further, we will click on the test link at the bottom of the output. This will take us into the StackHawk platform to explore further.

After clicking on the link, we can now see the test results nicely formatted. Next, we will click on the Possible Broken Function-Level Authorization (BFLA) entry.

Within this entry, we can see an Overview and Resources that can help us with fixing this vulnerability as well as the Request and Response that the API returned. Above this, you will also see a Validate button, which will display a cURL command with the exact API request used to expose the vulnerability.

Fixing The BFLA Vulnerability

To fix the BFLA vulnerability in the Node.js API, you must implement authentication and authorization checks. This will ensure that users can only access the endpoints that their role permits. In this case, we will do a lookup in the database for the user, return their role, and then do the authorization check. This will be done within the `authorizeAdmin` function in the code below.

For simplicity, I'll demonstrate a basic version of these checks. In a real-world application, you'd likely use more robust authentication and authorization mechanisms and platforms, such as Auth0 or Okta, to control access and handle credential creation.

To remedy our BFLA vulnerability, update your app.js with the following code:

The updated code above introduces several significant enhancements and changes compared to the original version, specifically focusing on security through the use of JSON Web Tokens (JWT) for authentication and authorization to eliminate the BFLA vulnerability.

The updated code introduces the jsonwebtoken package to implement JWT-based authentication and authorization. This is a significant enhancement over the original code, which did not include any form of user authentication or authorization. To use this, you’ll also see the addition of the constant JWT_SECRET defined, which is used to sign and verify JWTs. This key is essential for the security of the token-based system, ensuring that tokens are valid and issued by the server. Of course, the key is extremely simple since it is just for demonstration purposes. In a production system, you’ll want to have a longer and more complex key that is not directly defined in the code!

The updated code also defines a method called authenticateJWT, a middleware function that checks for the presence of a JWT in the Authorization header of incoming requests. It verifies the token using the JWT_SECRET. If the token is missing or invalid, it sends a 401 or 403 response, effectively securing the endpoint from unauthorized access.

Next, the authorizeAdmin middleware function is defined, which checks if the authenticated user (decoded from the JWT) is authorized to access the admin-only endpoint. The comparison is made by retrieving the user's role from the database, based on the sub/ID field in the JWT. With the role retrieved, we then check to ensure it equals “admin”. With this check in place, the PUT /users/:id endpoint is now protected by the authenticateJWT and authorizeAdmin middleware, arranged in an array. This sequential middleware arrangement ensures that every request to this endpoint is first authenticated and then authorized, a common pattern to enforce security on API endpoints.

Once the code has been updated on your side, you can stop the currently running server (by using ctrl + C in the terminal) and restart it with the new code using:

node app.js

The app should now be up and running with the updated code!

Confirm the fix!

With the latest code, users must send a JWT along with their request in the Authorization header. The code will then extract the sub field, retrieve the user's role from the database, and then check to ensure they have the admin access needed to perform the function they are trying to do. In the JWT.io debugger, this is how such a token would look:

Now, let’s confirm the fix in StackHawk. To do this, we will click the Rescan Findings button back in StackHawk.

Then, we will see a modal containing the “hawk rescan” command that includes the correct Scan ID. You’ll run this command in the same terminal where you ran the initial set of tests.

In the output, you will again see any vulnerabilities found in the scan. In this case, you’ll see that the BFLA vulnerability is no longer showing. Clicking on the link at the bottom of the terminal output, you can confirm that the BFLA vulnerability has now been added to the Fixed Findings from Previous Scan, confirming that the vulnerability has been successfully fixed and has passed any vulnerability tests.

With that, we’ve successfully remedied and retested our API to ensure its safety from potential BFLA attacks. Please remember that the code above is for demonstration purposes and that adding robust, production-grade authorization to an API endpoint is much more involved than we implemented above. Using an API gateway, Role-based Access Control (RBAC), and identity provider, such as Auth0, is one of the best ways to prevent BFLA and secure your APIs from unauthorized use.

Why StackHawk?

When it comes to preventing vulnerabilities, such as BFLA, StackHawk offers a comprehensive platform for developers to secure their applications and APIs. StackHawk is a modern, powerful DAST tool designed for developers to integrate application security testing seamlessly into their software development lifecycle. It is not just another security tool; it's a developer-first platform emphasizing automation, ease of use, and integration into existing development workflows.

With StackHawk, developers and security teams can:

Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.

Conclusion

In this blog, we have looked deeply into the complexities of Broken Function Level Authorization (BFLA) vulnerabilities. We unpacked the essence of BFLA, revealing how it emerges from insufficient authorization checks, allowing attackers to access functions beyond their permissions. The discussion illuminated the root causes, mainly seen through the lack of validation and authorization in API requests. We looked into understanding BFLA's mechanics and the significance of adopting a defense strategy encompassing strong authorization checks, RBAC, and a zero-trust approach, among other security best practices.

From a practical perspective, we looked at how to identify a BFLA vulnerability within a NodeJS application using StackHawk, a cutting-edge Dynamic Application Security Testing (DAST) tool designed for developers. By integrating security testing directly into the development workflow, StackHawk pinpointed the BFLA vulnerability and provided actionable insights to remediate it effectively. Through a simple example, we showcased the power of adding authentication and authorization middleware to secure API endpoints against unauthorized access, thus mitigating the BFLA threat we introduced in the original code.

Embracing StackHawk in your development cycle equips your team with the necessary tools and insights to tackle security vulnerabilities, including BFLA, preemptively. This approach not only enhances the security posture of your applications but also fosters a culture of security mindfulness among developers. Experience firsthand how StackHawk's seamless integration and developer-centric solutions can transform your application security testing workflow, ensuring your applications are robust against common API threats outlined in the OWASP API Security Top 10. Sign up for a free trial of StackHawk today and join the ranks of proactive developers who are “shifting left” and making API security an integral part of their development process with StackHawk.

Finding and Fixing BFLA Vulnerabilities in Flask (Python) With StackHawk

StackHawk

Let's explore BFLA in more detail, including its nature, common root causes, and how to pinpoint BFLA vulnerabilities in your API code. Following this, we'll use StackHawk to scan a susceptible Flask application, locate a BFLA vulnerability in one of our endpoints, and then implement the necessary fix. Finally, we'll re-scan to validate that the vulnerability has been patched. Let’s begin by digging into the foundations of BFLA vulnerabilities.

What is Broken Function Level Authorization (BFLA)?

How Does BFLA Differ from BOLA?

What is The Root Cause of BFLA?

BFLA vulnerabilities typically stem from development practices that prioritize convenience over robust authorization. Here are several common contributing factors:

Oversimplification of Authorization: APIs that rely on basic checks without considering the full range of functions they expose are vulnerable to exploitation.
Lack of Consistent Authorization: Inconsistent or absent authorization across various API endpoints creates potential entry points for attackers.
Blind Trust in User-Supplied Data: All information users provide must be treated cautiously and validated, including parameters that might influence the accessed functionality.
"Security Through Obscurity": Relying on hard-to-guess API paths or obscure naming conventions offers a false sense of security. Determined attackers can often bypass these.

At its core, BFLA arises from the absence of robust and function-specific authorization controls embedded directly into the API's design.

Preventing Broken Function Level Authorization (BFLA) Vulnerabilities

The key to avoiding BFLA vulnerabilities lies in adopting a comprehensive approach encompassing secure design, robust authorization, and continuous monitoring. Here are some best practices:

Enforce Rigorous Authorization Checks: Validate users' permissions with each attempted access to an API function.
Least Privilege Principle: Limit user and application access to the minimum necessary functions and data required.
Input Validation: Carefully scrutinize all input data from users, particularly values that can influence what API functions are accessed.
Regular Security Testing: Automate security testing tools like StackHawk and employ penetration testing to uncover vulnerabilities like BLFA proactively.
Developer Education: Train your development team in secure coding practices with awareness of BFLA and similar vulnerabilities.

By following these guidelines, you'll significantly reduce your application's risk of BFLA vulnerabilities, ensuring users can only access what they're supposed to. Now, let’s put this into practice by looking at a vulnerable Flask application and using StackHawk to identify the BFLA vulnerability and help us verify that the fix we will implement successfully remediates the issue.

Detecting and Fixing BFLA Vulnerabilities in Flask (Python)

Building The Vulnerable Endpoint

Below is an example of a simple Flask API with a BFLA vulnerability. This API allows users to delete a user based on a user ID in the URL. However, it doesn't perform any checks to ensure that the user making the request has the applicable role, being an “admin, before running the logic within the endpoint. This demonstrates a BFLA vulnerability in its simplest form, allowing an unauthorized user to perform a function they shouldn’t have access to.

Please note: This is an intentionally vulnerable API for demonstration purposes. Do not use this code in an actual application, as it is not production-ready.

First, create a new directory for your project and navigate into it. If you do this through a terminal, you can run the command below.

mkdir bfla-api-example

cd bfla-api-example

Next, with the terminal, point to the root directory and initialize a new Python project/virtual environment using the following command.

python3 -m venv venv

source venv/bin/activate

Finally, before we write any code, we will install the following dependencies:

Flask: for setting up the server.
Flask_SQLAlchemy: for ORM support.
Flask_RESTx: for generating OpenAPI specs and other REST functionalities

To do this, using the same terminal pointed to the project root, run the following:

pip install Flask Flask_SQLAlchemy flask-restx

Now, we will begin to create our API application. In the root directory of the project, create a file named app.py. This file will contain your Flask server and the API endpoint, including the BFLA vulnerability.

After creating and opening the app.py file, add the following code

Let's run through a quick breakdown of the updated code, which demonstrates how to create a simple web server using Flask, Flask-SQLAlchemy for database interactions, and Flask-RESTx for building REST APIs with built-in OpenAPI (Swagger) documentation. The code provides a REST API for accessing and modifying user information stored in a SQLite database configured for simplicity and demonstration purposes.

1. Initialization of Flask App

app = Flask(__name__) Initializes the Flask application, setting up the basic environment for the API server.

2. Configuration for SQLAlchemy and Database

SQLALCHEMY_DATABASE_URI specifies the database connection, which is a SQLite database located at a specified path on the local filesystem.
SQLALCHEMY_TRACK_MODIFICATIONS sets this variable to False to disable modification tracking to prevent overhead, improving performance since track modifications aren't needed for this example.

3. Database Model Definition

class User(db.Model) defines the database model for users, specifying the table name and columns (id, name, role). This model is essential for interacting with the users table in the SQLite database.

4. Inserting Example Users

insert_example_users() is a function that checks if the user table is empty and populates it with initial data. This is useful for demonstrations and ensures there is data to work with when the API is first run.

5. API and Namespace Configuration

api = Api(...) sets up the Flask-RESTx API manager, which handles the routing and documentation of the RESTful API.
ns = api.namespace(...) defines a namespace for user operations, organizing endpoints under a common path and documentation category.

6. API Endpoint Definitions

The GET Endpoint, defined within UserResource, allows clients to fetch user data by ID. It uses a parameterized SQL query to retrieve data securely, preventing SQL injection.
The PUT Endpoint, also defined within UserResource, allows for updating user data by ID. This method similarly uses parameterized SQL queries for secure database interactions. The include=False parameter in the @ns.doc decorator means that the endpoint will be excluded from automatic API documentation generation, since it is considered a private API for the purposes of this example.

7. OpenAPI Specification Endpoint

@app.route('/api-spec/') serves the generated OpenAPI (Swagger) specification, which provides a machine-readable description of the available API endpoints. The function also manually removes documentation for the PUT method, aligning with its intended restricted access.

8. Server Initialization

The if __name__ == '__main__' block includes commands to initialize the database tables, insert example data, and start the Flask development server on port 4000. This makes the API accessible to clients and ensures that the server starts with the necessary setup completed.

After this code is running, we will have an example Flask app with a SQLite backend for handling simple user data operations. This example shows how to create a basic REST API and how to selectively document API endpoints using OpenAPI specifications, hiding methods from the spec that shouldn’t be publicly available. That being said, there still is a gap regarding the actual authorization of the PUT endpoint meaning that anyone can access the function, and this is where the BFLA vulnerability exists.

Running The Code

Now that our code is complete, it’s time to run the application and bring up our API. To run your API, run the following command in a terminal pointed to the root of your project with your virtual environment still active:

flask run -p 4000

Once the application is up and running, you’ll notice that the PUT /user/:id endpoint allows anyone to update user data by specifying a user ID in the URL. This is a straightforward example of a BFLA vulnerability we must remediate.

To demonstrate this, we can issue the following cURL command and see that it works, updating the user without any type of authentication or authorization.

Detecting The Vulnerability With StackHawk and HawkScan

Now that our code is set up and our API is running, let’s get StackHawk to identify this vulnerability automatically. To do this, you’ll need to ensure you have a StackHawk account. If you need one, you can sign up for a trial account or log into an existing account.

If you’re logging into an existing StackHawk account, from the Applications page, you’ll click Add an App -> Create Custom App.

Enabling BFLA Detection in HawkScan

To set HawkScan up with the "OpenAPI - Experimental" policy, you will log into StackHawk, go to the Applications screen, and click on the settings link for your application.

Next, on the Settings screen, under HawkScan Settings, click the Applied Policy dropdown and select the "OpenAPI - Experimental" policy.

Next, click the Edit Policy button right beside the dropdown.

On the next screen, under the Plugins and Tests section, click on the BFLA entry to enable HawkScan to execute tests for potential BFLA vulnerabilities.

Now, with our application set up in StackHawk, our stackhawk.xml has been added to the root of our API project, and BFLA detection has been enabled, we can finally test our application.

Run HawkScan

To test our application, in a terminal pointing to the root of our project, we will run HawkScan using the following command:

hawk scan

After running the command, the tests should execute in the terminal.

This will run tests against our API based on the OpenAPI spec using the OpenAPI Spider provided by StackHawk.

Explore The Initial Findings

After clicking on the link, we can now see the test results nicely formatted. Next, we will click the Possible Broken Function-Level Authorization (BFLA) entry.

Within this entry, we can see an Overview and Resources that can help us with fixing this vulnerability as well as the Request and Response that the API returned. Above this, you will also see a Validate button, displaying a cURL command with the exact API request used to expose the vulnerability.

Fixing The BFLA Vulnerability

To fix the BFLA vulnerability in the Flask API, you must implement authentication and authorization checks. This will ensure that users can only access the endpoints that their role permits. In this case, we will look up the database for the user, return their role, and then do the authorization check. This will be done within the `authenticate_and_authorize` function/decorator in the code below.

For simplicity, I'll demonstrate a basic version of these checks. In a real-world application, you can use more robust authentication and authorization mechanisms and platforms like Auth0 or Okta to control access and handle credential creation.

In the code, we will now use PyJWT to check out various aspects of the JWT to authenticate and authorize the user. To install this dependency, run the following in the terminal: pip install PyJWT

Next, to remedy the BFLA vulnerability in the code itself, update your app.py with the following code:

This code creates a method we will attach to the endpoint. In this code, we will extract the JWT from the Authorization header, then we will read the “sub” claim, which contains the user's ID. We then retrieve the user's role and ensure that their role is “admin” before granting them access to the endpoint. This is a straightforward implementation that will need to be bulked up for production use cases, but it gets the point across. Of course, the JWT Secret is extremely simple since it is just for demonstration purposes. In a production system, you’ll want to have a longer and more complex key that is not directly defined in the code!

We will then add the code below, adding the @authenticate_and_authorize decorator to the PUT route and overwriting the existing route logic that does not require auth.

In this code, we are simply adding one thing to the PUT endpoint in our UserResource class: the @authorize_and_authenticate line, which adds the function we implemented above into the processing of the API request and making sure the user is authenticated and authorized to access the endpoint.

Overall, once these changes are added, the end-to-end code will now look like this:

Once the code has been updated on your side, you can stop the currently running server (by using ctrl + C in the terminal) and restart it with the new code using:

flask run –port=4000

The app should now be up and running with the updated code!

Confirm the fix!

Now, let’s confirm the fix in StackHawk. We will click the Rescan Findings button back in StackHawk to do this.

Then, we will see a modal containing the “hawk rescan” command that includes the correct Scan ID. You’ll run this command in the same terminal where you ran the initial set of tests.

In the output, you will again see any vulnerabilities in the scan. In this case, you’ll see that the BFLA vulnerability is no longer showing. Clicking on the link at the bottom of the terminal output, you can confirm that the BFLA vulnerability has now been added to the Fixed Findings from Previous Scan, confirming that the vulnerability has been successfully fixed and has passed any vulnerability tests.

Why StackHawk?

With StackHawk, developers and security teams can:

Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.

Conclusion

From a practical perspective, we looked at how to identify a BFLA vulnerability within a Flask application using StackHawk, a cutting-edge Dynamic Application Security Testing (DAST) tool designed for developers. By integrating security testing directly into the development workflow, StackHawk pinpointed the BFLA vulnerability and provided actionable insights to remediate it effectively. Through a simple example, we showcased the power of adding authentication and authorization middleware to secure API endpoints against unauthorized access, thus mitigating the BFLA threat we introduced in the original code.

Discover the Best API Discovery Tools in 2024

StackHawk

Selecting the right API discovery tools plays a huge role in API integration, API management, and many other areas where understanding your entire API portfolio is critical. These tools can help ensure that every API connected to your organization is discovered and cataloged, which is a major part of ensuring that APIs are secure. Without understanding every aspect of your organization's APIs, it's hard to keep them compliant, secure, and well-utilized.

This guide will examine how API discovery can streamline many parts of your workflow. We will demystify and compare the top API discovery tools available in 2024, discover their advantages and use cases, and cut through the noise to give you the answers you need to figure out which tools will suit you best for discovering APIs within your ecosystem. Let's begin by looking at API discovery tools and how they work.

Navigating the World of API Discovery Tools

API discovery involves understanding an API's efficiencies and real-time functionalities, typically done through various methods. This includes a mix of manual and automated tasks, with the end goal of identifying what APIs an organization has under its umbrella to accelerate app development by understanding the API capabilities. Of course, from the security perspective, API discovery helps to identify how data flows throughout the various APIs, which can help identify any gaps that could lead to a security vulnerability. With the help of a discovery API, organizations can take a crucial step to manage and harness the power of APIs efficiently.

API discovery tools help by:

pinpointing and managing all the APIs in your digital systems
empowering developers to comprehend and utilize existing APIs, eliminating the need to create new ones
conserving time and promoting efficient integration
catering to different cybersecurity needs, including a proactive approach to API security

Defining API Discovery Tools

API stands for Application Programming Interface, which details how software components should interact. RESTful APIs are the most familiar style for modern web application programming interfaces, allowing data to be sent and received between systems, most frequently between a front and backend application. On the other hand, API discovery is the process of identifying and cataloging the APIs present within an organization. Think of automated API discovery tools as a librarian designed to automatically locate, document, and construct a catalog of an organization’s APIs. The primary objective of an API Discovery feature is to construct a centralized repository or catalog that lists all APIs, guaranteeing easy discovery and efficient utilization.

The Role of API Discovery in Digital Transformation

When it comes to digital transformation initiatives, they often involve the integration of new software and services. In many of these transformation initiatives, APIs serve as the key enablers of this integration. APIs are essential for the connectivity between different systems and services, as they allow for the sharing of functionalities and data.

API discovery tools offer an automated method for recognizing and cataloging APIs throughout the enterprise. These tools aid in comprehending the functionalities of various APIs so that API consumers can understand where and how they may be able to use a particular API. By informing developers about available APIs, API discovery can promote integration and usage of these APIs within software projects. By leveraging these API catalogs and discovery, businesses can optimize the use of their existing APIs for new purposes, enhancing the efficiency of their digital transformation efforts.

Especially in the cases where APIs have not been documented well or vast portfolios of APIs exist, API discovery can significantly influence digital transformation by allowing organizations to swiftly identify and integrate with multiple systems through the available APIs found through the API discovery tool.

Unveiling Top API Discovery Solutions

As we explore the realm of API discovery, it’s vital to recognize the tools that are at the forefront. These tools help to automate and make the API discovery process very efficient. Choosing the right API discovery tool can be daunting, given the many options available. However, understanding the criteria for selecting an API discovery tool can enable you to make an informed decision to ensure the selected tool matches your particular needs. In this section, we’ll look at the leading API discovery solutions and discuss the factors to consider when choosing a tool to fit your use case.

Criteria for Selecting an API Discovery Tool

Although many tools and features are available, we can boil down core functionalities to look for in four categories: automation, integration, security, and ease of use. These critical factors need to be considered when selecting an API discovery tool. Let's take a look at these four pillars in more depth:

Automation: A good API discovery tool helps automate the recognition of APIs in an organization. The tool's automated processes should be configurable and allow you to dial in the discovery process as much as possible.
Integration capabilities: The tool should be able to integrate with existing systems and technologies within your stack.
Security features: The tool should have robust security features to protect sensitive data and prevent unauthorized access. The tool may also help you identify any security issues within the APIs it discovers.
Ease of use: The tool should be user-friendly and easy to navigate. Configuration and deployment should be seamless and not require much effort to initiate the discovery process.

At a high level, these factors will help you choose the right API discovery tool based on your needs, with very simple criteria to follow. Most API discovery tools are bundled as features within wider platforms, whether an API security tool or an API management platform. So, you should also ensure that the platform's other features also fit your use case/technology stack and check if there are other features you could leverage as well.

Highlighting Industry-Leading API Discovery Software

API discovery solutions are relatively abundant; however, not all these tools are created equally. Several tools stand out due to their robust features and user-friendly interfaces. Let's take a quick look at the range of powerful tools that can streamline API management and security with API discovery capabilities. Here are a few leading solutions to be aware of:

StackHawk: StackHawk couples its well-established DAST (Dynamic Application Security Testing) capabilities with API discovery. This combination offers a powerful toolset for identifying and securing your API landscape.
Salt Security: This platform emphasizes proactive security measures, including real-time analysis and prevention of API attacks. It offers seamless integration capabilities to fit within existing environments.
Noname Security: Dedicated to comprehensive asset security, this tool covers various aspects such as API discovery, posture management, runtime protection, and security testing.
Memcyco: This solution goes beyond traditional API discovery to actively prevent website spoofing fraud and safeguard online brand reputation.
APIsec: Focused on robust security mechanisms and thorough monitoring, this solution aids organizations in identifying and mitigating risks associated with shadow APIs. It integrates well with platforms like AWS API Gateway for streamlined protection.
Wallarm: This platform prioritizes API security with comprehensive monitoring, protection features, and assistance in discovering and managing shadow APIs, contributing to enhanced overall security posture.

Of course, this is just a small selection of many of the API discovery tools available on the market. Choosing the right tool depends on your specific security needs, integration requirements, and the size/complexity of your API ecosystem.

Enhancing API Security Through Discovery Tools

When it comes to the benefits that API discovery tools bring to an organization, their contribution towards enhancing API security is definitely up high on the list. API discovery involves recognizing all APIs, including those that are concealed or overlooked. By making sure that every available API is discovered and cataloged, API discovery tools can help guarantee comprehensive security and lessen the risk of cyber threats. By understanding an organization's entire API portfolio, teams can work more effectively to safeguard digital assets by identifying all APIs and ensuring they adhere to security standards. Knowing all active APIs is critical for ensuring they are continuously monitored and protected, enhancing overall security since if an undocumented API has a security issue, it likely will not be found until it is exploited.

Three particular types of APIs can degrade an organization's security posture: shadow, zombie, and rogue APIs. Let's examine all three in more detail to understand what they are and how they can impact security.

Identifying and Securing Shadow APIs

Shadow APIs lurk within organizations and are created outside of any official oversight. While often well-intentioned, these APIs can widen your attack surface, lacking the security, documentation, and monitoring that centrally managed APIs typically have. API discovery tools are your key to uncovering them. By scanning network traffic, API gateways, and even code bases, they reveal APIs that might slip past traditional security measures.

Once you know a shadow API exists, you'll want to enforce the API standards across your organization within the API, conduct regular audits, and potentially implement API observability to monitor API calls to the endpoint. Finally, put those shadow APIs through the same rigorous security testing (with tools like StackHawk) that you would apply to any production API if you plan to keep them available.

Preventing Zombie and Rogue API Risks

Old, outdated zombie APIs and intentionally malicious rogue APIs both pose serious risks. Advanced API discovery tools can help you pinpoint these threats by analyzing API usage patterns and looking for anomalies that indicate trouble. Spikes in API traffic from unusual places, strange user-agent strings, or unexpected activity after hours can all be signs of an attack in progress.

When it comes to remedying these issues, deprecate zombie APIs in a controlled manner, giving developers time to update their code. Decisively block any suspected rogue APIs immediately while investigating further. Education is also key—make sure your developers understand the dangers and best practices to avoid accidentally creating these kinds of risky APIs and exposing them as potential attack vectors.

Leveraging API Discovery for Developer Productivity

API discovery tools are an essential element in the developer’s toolkit. These tools and the knowledge they bring to developers about an organization's API landscape can help developers find existing APIs that meet their needs, speeding up development processes and reducing duplicated efforts. API discovery tools foster collaboration between teams by making APIs easily discoverable, allowing developers to quickly identify who to contact regarding a specific API.

Facilitating Easy Access to API Documentation and Catalogs

Proper documentation of APIs, detailing their functionality, endpoints, authentication methods, and response examples, is crucial for developers to understand and properly utilize APIs. To fully leverage the APIs, developers must access API specifications, such as input/output formats, authentication requirements, and rate limits or quotas.

Once APIs are discovered and cataloged, API documentation tools can efficiently generate and maintain API documentation, ensuring consistency, accuracy, and comprehension for the developers using the API. They also facilitate collaborative efforts by allowing developers to share, review, and edit documentation seamlessly, minimizing the need for frequent direct communication.

Boosting Collaboration Across Development Teams

APIs support collaborative development by allowing real-time access to data and functionality, which is essential for decision-making and aligning team efforts. When it comes to organizations using a microservice-oriented approach, APIs can offer clear contracts for services, enhancing their usability. The double-edged sword of microservice APIs is that they generally have a large footprint regarding the number of APIs available across an organization. This is where API discovery can help teams keep track of all APIs within the microservice ecosystem for more close-knit collaboration.

This collaborative approach enhances the efficiency of the development process and fosters a sense of ownership and accountability among team members, while API discovery tools help to ensure that every API is accounted for and documented.

The Evolution of API Discovery: From Manual to Automatic

The world of API discovery has undergone a remarkable transformation. In the early days, finding and understanding available APIs was labor-intensive. Developers often resorted to internet searches or relied on potentially outdated documentation, spending massive amounts of effort and time to discover and understand the APIs they wanted to use. Although users may have known that an API existed, there may not have been any documentation or easy way to confirm its existence or how to consume it.

This landscape changed as APIs themselves evolved. The move from SOAP-based (Simple Object Access Protocol) web services, with their reliance on descriptive files like WSDL, to the flexible world of REST APIs and the OpenAPI specification created opportunities for innovation in discovery. No longer bound by strict definitions, APIs could be more dynamic, demanding new tools to uncover them. Compound this with the number of new APIs being introduced daily; manual methods were no longer feasible for API discovery.

The Shift from Manual to Automated Processes

The transition from manual API discovery to streamlined automation marks a turning point. Automated tools don't just save time; they transform how we interact with APIs. By actively scanning network traffic and code repositories and even using pattern-matching heuristics, these tools reveal a comprehensive view of your API landscape. This heightened awareness is crucial for effective management, security, and innovation. Many tools can compound the insights retained from API discovery tools with other parts of their platform, such as how StackHawk can use API discovery to identify all endpoints and then test them for security flaws with its DAST (Dynamic Application Security Testing) capabilities.

Embracing Automation for Enhanced API Visibility

Fully embracing automated API discovery tools grants us unprecedented visibility into complex API ecosystems. Imagine a continuously updated map of every API in your organization, highlighting not just what exists but how APIs are used, who interacts with them, and the sensitivity of the data involved. This visibility is a game-changer. It helps proactively uncover forgotten "zombie APIs" that might still expose data and alerts you to a developer's well-intentioned but potentially insecure shadow API. With this knowledge, developers and their organizations can take decisive action: tighten security, streamline processes, and drive better API design and management.

StackHawk + API Discovery

StackHawk customers repeatedly see the power of our API security testing – the comprehensive coverage, the seamless CI/CD integration, and that feeling of confidence. But there's a catch, a recurring challenge: they're often only securing a fraction of their APIs. Our analysis reveals a worrying truth: many security teams are in the dark about a huge chunk of their attack surface. It's nobody's fault; software moves fast, and security often struggles to keep pace. The way we test and manage APIs needs to come up to speed.

That's why we built API Discovery Powered by HawkAI. It's the missing piece in the API security puzzle. Think of it as a spotlight in the dark, revealing hidden APIs that attackers could exploit. With this newfound knowledge, you can extend the same rigorous testing and automation you rely on with StackHawk to the entirety of your API landscape. No more blind spots, no more surprises, just the control every security team needs and deserves.

Discovery – Understanding Your Attack Surface

Modern software development is inherently complex, making it challenging for security teams to pinpoint all the "things" in software applications they need to test. At StackHawk, we believe that Source Code is the Source of Truth, and HawkAI takes an inside-out approach, empowering developers and AppSec teams to achieve security and speed. Here's how it works:

Effortless Integration: Connect your code repositories to StackHawk.
AI-Powered Identification: HawkAI utilizes intelligent algorithms to identify repositories containing running applications and APIs.
Attack Surface Defined: Uncover previously unknown APIs and gain a comprehensive view of your attack surface.
Progress Tracking: Monitor your progress toward achieving complete API coverage.

Observability – Keeping Pace with Change

Once you have a handle on your assets, how do you ensure your security processes keep up with constant code changes? StackHawk adds further functionality to improve your security posture with the following:

Continuous Monitoring: HawkAI tracks how often code is deployed to your assets and compares it to your testing frequency.
Policy Alignment: Identify discrepancies between your security policies and actual testing coverage.
Success Support: We're here to help your security team refine its program and maximize its effectiveness.

StackHawk goes beyond traditional API discovery tools, pairing discovery with our powerful, API-focused DAST capabilities. This means newfound security doesn't just stay on paper—you can immediately test those discoveries, ensuring your organization's security posture is truly strengthened.

HawkAI digs deeper than just finding APIs. It bridges the gap between security and development teams. Discover an untested asset? HawkAI pinpoints the developer who last touched it, enabling direct collaboration for rapid understanding and action. No more security roadblocks, just streamlined processes that get APIs secured quickly.

At StackHawk, we believe AI isn't just a buzzword. It's a tool to empower security and developers to prioritize what matters most: secure, high-quality software. HawkAI embodies this by delivering a comprehensive API discovery solution that doesn't just find problems; it helps you solve them – quickly.

Conclusion

APIs are the backbone of modern software, but their vast numbers and the rapid pace of development make it difficult to know what you have and keep it all secure. In this blog, we covered:

What API discovery is and how it works
Benefits for security, developer productivity, and digital transformation
Top tools and how to choose the right one
The shift from manual to automated discovery

Lastly, we took a look at StackHawk's latest API discovery capabilities and how StackHawk's new API Discovery Powered by HawkAI goes beyond traditional tools:

Illuminates your entire attack surface: Uncover shadow, zombie, and rogue APIs with AI-powered insights.
Bridges the dev-security gap: Collaborate directly with developers to secure newly discovered APIs quickly.
Secures at the speed of development: Seamless API discovery and our best-in-class DAST ensure your security keeps pace with innovation.

StackHawk's API Discovery Powered by HawkAI is currently in closed beta. Want to see it in action? Schedule a demo of StackHawk's comprehensive API security platform.

How API Discovery Empowers AppSec Professionals and Fuels Innovation

Nicole Jones

As application security (AppSec) professionals, we understand the constant struggle to secure our ever-expanding digital landscapes. APIs often become blind spots, creating sleepless nights and doubts in our attack surface coverage.

But there is a solution— adopting a continuous API discovery process. One that doesn’t involve manually tracking down API endpoints.

Owning Your API Attack Surface

Imagine a world where:

Security Audits Become a Breeze: No more scrambling to identify in-scope APIs. A comprehensive inventory streamlines security assessments.
Developers Get What They Need, Fast: APIs are easily discoverable and documented, accelerating development cycles.
Risk Management Gets Real: Proactive identification of all APIs empowers you to prioritize threats and allocate resources effectively.
Breaches Become a Distant Memory: With all APIs identified and secured, you significantly reduce your attack surface.

These are just a few of our favorite outcomes achievable with a strong API discovery process.

How to Get There

Leading companies and security teams are embracing API discovery with urgency. Here's how they're doing it:

Leveraging Automation: Automated discovery tools take the heavy lifting out of finding APIs, saving valuable time and effort.
Centralized Inventory: A single source of truth for all APIs, including ownership, functionality, and access controls, ensures everyone is on the same page.
API-Centric Security: Security considerations are woven into the entire API lifecycle, from design to deployment.
Collaboration is Key: Open communication between AppSec and development teams fosters a culture of API security awareness.

Unlocking Your Holistic View

Building a holistic view of your API attack surface can be approached in a few different ways:

Network Scanning: Identify APIs within your network infrastructure.
Code Analysis: Uncover APIs embedded within applications and microservices.
Developer Engagement: Encourage developers to register and document their APIs during creation.
Legacy System Integration: Develop strategies to discover APIs within older, potentially undocumented systems.

Any one of these techniques will help you better understand your API landscape but deploying a combination of these methods is even better. For an efficient proactive approach, we recommend starting with code analysis and developer engagement.

Benefits Beyond Security

The benefits of a holistic API view extend far beyond just security. AppSec professionals, developers, and organizations as a whole will reap a multitude of positive changes:

Increased Confidence: Knowing you've secured all APIs creates a sense of control and accomplishment.
Reduced Stress: No more sleepless nights worrying about hidden vulnerabilities.
Empowered Developers: Faster API discovery improves developer productivity and innovation.
Improved Collaboration: A shared understanding of APIs fosters better communication across teams.

API discovery isn't just about plugging security holes; it's about owning your overall attack surface. By taking control of your API landscape, you can achieve a more secure, efficient, and collaborative development environment.

StackHawk's API Discovery capability is now in open beta. If you're interested in learning more, read our documentation here.

StackHawk Announces Integration with Microsoft Defender for Cloud

StackHawk

DENVER, Colorado - May 07, 2024 - StackHawk, the company delivering API and application security testing as part of modern software delivery practices, announced a new integration with Microsoft Defender for Cloud to help organizations build software more securely. APIs are crucial to building modern applications. As a result, the API layer has become a critical security risk for many organizations. Efficient and proactive API security testing remains a pivotal challenge for security teams looking to strengthen their API security posture.

StackHawk’s latest product integration with Microsoft Defender for Cloud – a cloud-native application protection platform, gives security professionals greater visibility into the security status of their APIs during the time of development within one unified viewpoint and complements the runtime API security capabilities provided by Defender for APIs. The integration with StackHawk will enable users to aggregate API security findings and posture insights across multiple tools, providing AppSec professionals with a correlated view of current risks and a more integrated approach to securing APIs.

StackHawk continues to bridge the gap between application owners and security teams by combining shift-left and developer automation with visibility and insights into the health of an organization’s security posture. This latest product integration adds to StackHawk’s existing integrations across the Microsoft and GitHub ecosystems, allowing engineers to automate security testing via GitHub Actions and GitHub Advanced Security and now giving AppSec teams the API Security insights and oversight with Microsoft Defender for Cloud.

Microsoft customers looking to prioritize API security testing now have a seamless path with StackHawk. The StackHawk platform is intricately woven into the Microsoft ecosystem. Developers can quickly activate a free trial of StackHawk, integrating security testing workflows with CI/CD platforms like GitHub Actions or Azure DevOps.When graduating from the free tier, Microsoft customers can purchase StackHawk through the Azure Marketplace to reduce or completely eliminate procurement time. Information about how to integrate StackHawk scan results into Defender for Cloud can be found here.

“StackHawk’s integration with Microsoft Defender for Cloud extends the ability to assess the API security posture of an application beyond what’s happening in production,” said Joni Klippert, CEO and co-founder at StackHawk. “The StackHawk platform is designed to support teams in identifying and fixing API security vulnerabilities earlier in the development process while delivering secure code prior to production. This collaboration with Microsoft will enable customers to seamlessly pinpoint API security risks across their entire API ecosystem, strengthening their security posture.”

“Our collaboration with StackHawk builds upon Defender for Cloud’s current API security capabilities, providing our customers with a proactive approach to identifying vulnerabilities in APIs,” said Vlad Korsunksky, Vice President, Cloud & Enterprise Security at Microsoft. “Working together with StackHawk, we equip security teams with the knowledge, context and clarity needed to identify and mitigate API security risks across their entire lifecycle.”

For more information about how StackHawk integrates with Microsoft Defender for Cloud, please visit: https://www.stackhawk.com/partners/microsoft/

Additionally, customers can purchase StackHawk through the Microsoft Azure Marketplace.

About StackHawk StackHawk is making API and application security testing part of software delivery. The StackHawk platform empowers engineers to easily find and fix application security bugs at any stage of software development. With a strong founding team that has deep experience in security and DevOps, and some of the best venture investors in the business, StackHawk is putting application security testing into the hands of engineers. Learn more and sign up for a free trial at www.stackhawk.com.

Media Contact Sena McGrand Lumina Communications for StackHawk stackhawk@luminapr.com

StackHawk Secures Top Honor in 2024 Global Infosec Awards at RSA 2024

StackHawk

DENVER, May 6, 2024 -- StackHawk, the company making application security testing part of software delivery, today announced that the company was named winner of ‘Most Innovative API Security’ in the 12th Annual Global Infosec Awards at RSA 2024. These prestigious global awards, by Cyber Defense Magazine, recognize innovators with compelling value propositions for their products in competitive infosecurity industries.

“Being honored as a winner is a testament to our team's continued pursuit of excellence and commitment to redefining application and API security,” said Joni Klippert, CEO and co-founder of StackHawk. “This recognition underscores our dedication to providing cutting-edge solutions that not only meet but exceed our customers' expectations. We are incredibly proud of this achievement and excited to continue leading the way towards furthered innovation in API Security.”

A developer-centric API security testing tool ensures more vulnerabilities can be addressed during the development stage of software delivery, reducing hours spent triaging bugs found in production, and helping scale AppSec teams. The platform enables diligent prioritization of security bugs earlier in the development process to avoid schedule disruption and help teams identify and investigate high priority issues, allowing them to fix security bugs prior to production at the accelerated rate of software delivery.

“StackHawk embodies the key attributes we seek in winners: a proactive approach to understanding future threats, delivering cost-effective solutions, and innovating in unexpected ways to mitigate cyber risks and stay ahead of breaches," said Gary S. Miliefsky, Publisher of Cyber Defense Magazine. "StackHawk is unquestionably deserving of this prestigious award and consideration for implementation in any environment,"

This announcement comes just on the heels of StackHawk’s integration with Microsoft Defender for Cloud, which will help organizations build software more securely. The company also recently announced the availability of StackHawk Pro and StackHawk Enterprise in the Microsoft Azure Marketplace, and the closed beta of 'API Discovery powered by HawkAI" which leverages AI to give Security teams improved insights of their API and Application attack surface. These offerings provide security teams with ongoing discovery and visibility into their organization's attack surface. They enable teams to pinpoint gaps in coverage, align security testing with the fast pace of software development, and collaborate more effectively with code-writing engineers.

About StackHawk

StackHawk is making application security testing part of software delivery. The StackHawk platform offers engineering teams the ability to find and fix application bugs at any stage of software development. Built by a strong founding team with deep experience in security and DevOps, and funded by some of the best venture investors in the business, StackHawk is leading the shift left movement by putting application security testing into the hands of engineers the moment they build code. Learn more and sign up for a free trial at www.stackhawk.com.

About Cyber Defense Magazine

Cyber Defense Magazine is the premier source of cyber security news and information for InfoSec professions in business and government. We are managed and published by and for ethical, honest, passionate information security professionals. Our mission is to share cutting-edge knowledge, real-world stories and awards on the best ideas, products, and services in the information technology industry. We deliver electronic magazines every month online for free, and special editions exclusively for the RSA Conferences. CDM is a proud member of the Cyber Defense Media Group. Learn more about us at https://www.cyberdefensemagazine.com and visit https://www.cyberdefensetv.com and https://www.cyberdefenseradio.com to see and hear some of the most informative interviews of many of these winning company executives. Join a webinar at https://www.cyberdefensewebinars.com and realize that infosec knowledge is power.

StackHawk Media Contact:

Sena McGrand

Lumina Communications for StackHawk

stackhawk@luminapr.com

CDM Media Inquiries:

Irene Noser, Marketing Executive

marketing@cyberdefensemagazine.com

www.cyberdefensemagazine.com

Building a Secure API Ecosystem Starts with API Discovery

Nicole Jones

When it comes to application security, we spend countless hours protecting our applications against ever-evolving threats— We patch vulnerabilities, implement robust authentication, and try to stay vigilant. Yet, we still don’t have a full picture of our attack surface at any given time.

The problem comes from not having a reliable way to continuously define and inventory our attack surface given how quickly software changes. This blog aims to explain why API discovery is no longer a “one-and-done” but an ongoing security imperative.

Warning Signs You're Not Aware of Your Entire Attack Surface

Ask yourself the following questions:

Fragmented Visibility: Do you struggle to get a complete picture of all APIs within your organization? Are there whispers of "shadow APIs" or undocumented APIs?
Repetitive Security Efforts: Are you constantly reinventing the wheel when it comes to API security assessments?
Slow Development Cycles: Does finding and integrating with relevant APIs become a roadblock for developers?

If you recognize any of these signs, you're likely facing an API discovery problem. Let's dispel some common myths that might be holding you back from addressing it.

Debunking the Myths

Myth #1: We Don't Have That Many APIs. Even small organizations have a surprising number of APIs, both internal and external. Complexity grows quickly, and manual tracking becomes unsustainable.
Myth #2: Our APIs Are Well Documented. Documentation is ideal, but it often lags behind development, and APIs can change over time. Discovery tools ensure you have the latest information.
Myth #3: Security Testing Covers It All. Security testing might identify some exposed APIs, but it's a reactive approach. Discovery offers a proactive way to find and secure all APIs.

The Costs of Inaction

Ignoring API discovery comes at a significant cost:

Wasted Resources: Duplicating security assessments and developer time spent searching for APIs leads to inefficiency and delays.
Poor API Governance: Without proper discovery, enforcing API security policies and managing access controls becomes a challenge.
Potential Security Breaches: We hate to state the obvious, but undiscovered APIs create a vulnerable attack surface. Hackers thrive on finding hidden APIs, potentially exposing sensitive data.

Securing Your API Landscape

The API landscape is constantly evolving. Here's how to stay aligned with software development:

Invest in API Discovery Tools: Automated tools can scan your network or source code to identify all APIs, documented or not.
Embrace a Centralized Inventory: Maintain a comprehensive catalog of all APIs, including ownership, functionality, and access controls.
Promote API Security Awareness: Educate developers and IT teams on the importance of secure API design and development practices.

By prioritizing API discovery, you gain a holistic view of your API ecosystem, enabling proactive security measures. This mitigates risks and fosters innovation by empowering developers to find and utilize valuable APIs quickly and securely.

Ready to explore your API landscape? Sign up for access to StackHawk's API Discovery Powered by HawkAI! Now in beta.

Re-Defining API Discovery: How We Designed API Discovery Powered by HawkAI

Scott Gerlach

At StackHawk, we've helped countless customers find tremendous value in our API security testing capabilities. We are repeatedly chosen for our ability to comprehensively test APIs and seamlessly automate testing within their CI/CD pipelines.

However, a recurring theme has emerged: customers are only uncovering a fraction of their total attack surface.

Our internal analysis of code repositories reveals that many security teams are not testing and are potentially unaware of a significant portion of their APIs. The fast pace of software development makes it difficult for security to keep up, creating this as a natural result. That's why we created API Discovery Powered by HawkAI, to help security teams keep up with software development and own their attack surface.

Discovery – Understanding Your Attack Surface

Modern software development is inherently complex, making it challenging for security teams to pinpoint all the "things" they need to test. At StackHawk, we believe that Source Code is the Source of Truth and HawkAI takes an inside-out approach, empowering developers and AppSec teams to achieve both security and speed. Here's how it works:

Effortless Integration: Simply connect your code repositories to StackHawk.
AI-Powered Identification: HawkAI utilizes intelligent algorithms to identify repositories containing running applications and APIs.
Attack Surface Defined: Uncover previously unknown APIs and gain a comprehensive view of your attack surface.
Progress Tracking: Monitor your progress toward achieving complete API coverage.

Observability – Keeping Pace with Change

Once you have a handle on your assets, how do you ensure your security processes keep up with the constant stream of code changes?

Continuous Monitoring: HawkAI tracks how often code is deployed to your assets and compares it to your testing frequency.
Policy Alignment: Identify discrepancies between your security policies and actual testing coverage.
Success Support: We're here to help your security team refine their program and maximize its effectiveness.

Understanding AI Concerns

We understand concerns regarding AI and have applied thoughtful guidelines throughout our development process:

Code Repository Access: HawkAI maintains read-only access to your repositories and does not have the ability to write or change code on your behalf.
Security: Your code and data are protected and will never be sent to third parties.
Transparency: HawkAI clearly indicates when AI is involved through the use of icons.

Leveraging Insights

HawkAI goes beyond just discovery. It provides valuable insights to collaborate with your development team. When you discover a previously untested asset, HawkAI identifies the last developer who committed code, allowing you to easily reach out and gain a deeper understanding of the asset's purpose. This fosters communication and streamlines the process of bringing the asset under security testing.

At StackHawk, we believe AI is a powerful tool to help security and developer teams prioritize security efforts and work more efficiently by focusing on what will move the needle toward delivering secure, high-quality software. HawkAI embodies this philosophy by offering a comprehensive approach to API discovery, ensuring your security efforts keep pace with software development.

Ready to own your attack surface coverage? Sign up to get access to the beta.

Understanding and Protecting Against API5: Broken Function Level Authorization

StackHawk

Like most modern applications, APIs require extensive authorization controls to safeguard data and functionality. When authorization controls break down, sensitive data and critical functions become exposed, leading to potentially disastrous consequences. When precisely diagnosing authorization-related vulnerabilities, the OWASP API Security Top Ten outlines several variants. One such variant, Broken Function Level Authorization (BFLA), is an API vulnerability to which users can perform actions or use functions they shouldn't have access to. Imagine an attacker gaining unauthorized administrative privileges on your platform, the ability to view other users' private data, or disrupting core operations through a vulnerable API endpoint—that's the risk BFLA poses.

In this blog, we'll delve into what BFLA is, how it's exploited, and the essential strategies and security controls you must implement to protect your APIs. We'll also explore how modern DAST (Dynamic Application Security Testing) solutions, specifically designed to find BFLA vulnerabilities, can significantly enhance API security. Mainly, we will look at StackHawk and how its DAST platform can help you find and fix these issues before they can be exploited. First, let’s take a deeper look at the nuances of BLFA, beginning with a closer look at what it is.

What is Broken Function Level Authorization (BFLA)?

Broken Function-Level Authorization (BFLA) occurs when an application or API fails to enforce authorization controls at the function level properly. This means users can access functionality, perform actions, or retrieve data that should be restricted based on their role or permissions.

We can imagine this description through a simple example to bring it to what it looks like in the real world. In most cases, applications and the APIs that power them often have different functions for different user types. Regular users might have basic profile updating capabilities, while administrators likely have the power to delete accounts, modify system settings, or access sensitive data across users. BFLA vulnerabilities occur when the restrictions that govern who and how users can use APIs aren't correctly implemented. In the example above, a regular user may gain admin privileges, allowing them to delete users from the application even though they should not be allowed to have access to this unauthorized functionality. This would be a consequence of BFLA.

A BFLA usually involves a few steps to execute. Here is a simplified outline of how attacks often work:

Mapping the API: An attacker analyzes API requests and responses, observing how different functions and endpoints are structured within an application's APIs.
Identifying Authorization Gaps: Next, attackers look for patterns in how the API maps permissions to functions. For example, can the attacker access an admin function by changing a simple parameter in the API call?
Exploitation: Once a potential vulnerability is spotted, the attacker experiments by sending requests intended for higher-privileged users or restricted functions, testing if the API will wrongly grant them access. If they are successful, the BFLA vulnerability has been successfully exploited.

If you read the above description and thought, “That sounds a lot like Broken Object-Level Authorization (BOLA)!”, you’d be somewhat correct. Both are related but involve slight nuances, hence why they are listed as separate vulnerability types within the OWASP API Security Top Ten. Let’s take a closer look at their differences and similarities.

What Are The Differences Between BFLA vs. BOLA?

While BFLA (Broken Function Level Authorization) and BOLA (Broken Object Level Authorization) are both dangerous API vulnerabilities, understanding their distinctions is crucial for effective protection:

The core issue surrounding BOLA centers on an attacker's ability to access data objects to which they shouldn't have rights. This often involves manipulating direct object identifiers within API requests.

For instance, let’s say there is an endpoint such as [GET] /patient/:patientID that allows users to access data about their personal medical profile. The user can only access their profile and private medical details if authorization is set up correctly. However, without the authorization checks in place, an attacker could change the patientID in the URL to include the ID of other patients, granting them access to their profiles and exposing personal data. In this scenario, this would be considered a BOLA vulnerability

With BFLA, the way the attack is executed and the results can be slightly different. In the case of a BFLA vulnerability, the issue arises when an API doesn't correctly restrict who can use what functions. Attackers gain the ability to perform actions meant for higher-privileged roles that should only be available to users in the upper user hierarchy.

Using the previous example, let's say that there is a corresponding [POST] /patient/:patientID endpoint that allows doctors to update charts, medical history, and diagnosis in a patient's profile. If an attacker has successfully realized that they have access to the [GET] endpoint, they can easily change the HTTP method to [POST], add false information to the request, and if the proper checks aren't in place, update a patient's medical records on the system even though it is not a legitimate request.

For a quick reference to compare the two, here’s a more concise look:

Both attacks are similar but with different outcomes and slightly different execution paths. That being said, there are some overlaps. BFLA and BOLA stem from the failure to correctly implement authorization logic within the API, which could lead to unauthorized data access or account takeover. However, you can think of BOLA as a subset of BFLA. BFLA addresses a broader range of authorization issues, encompassing unauthorized object access and the misuse of various API functions. While closely linked, BFLA highlights that API authorization flaws can lead to unauthorized access to both data and actions that a user shouldn't be able to perform.

The Root Causes of BFLA

BFLA vulnerabilities typically stem from development practices prioritizing ease of implementation without considering authorization controls to safeguard data and functions. Let's take a quick look at the most common factors contributing to the appearance of BFLA vulnerabilities within APIs.

Over-reliance on Object Identifiers: When APIs use predictable object references (like sequential IDs or easily guessable strings), attackers can manipulate them with simple changes in API requests, opening the door to unauthorized data access.
Lack of Ownership and Permission Verification: APIs must consistently verify two things on every request: that the user attempting an action owns the object they're targeting and that the user has the necessary permissions for that action. Omitting these verifications increases the risk of a BFLA vulnerability.
Blind Trust in User Input: Any data a user provides, including object identifiers and function parameters, must be treated as raw and potentially malicious. Thorough input validation and sanitization are essential to prevent injection attempts designed to break the API's logic.
Insufficient Focus on Authorization: Security can sometimes become an afterthought in development. This can lead to inconsistent authorization across different API endpoints or a complete lack of protection for specific functions. Unfortunately, some developers may not be aware that these types of attacks are possible, so authorization mechanisms are not included in the APIs' design.
The Fallacy of Obscurity: Developers might wrongly assume that using long, hard-to-guess object identifiers (e.g., UUIDs) is sufficient. These identifiers are better than sequential ones; however, determined attackers will still find ways to discover or predict them. Security through obscurity should not be relied upon.

When boiled down, BFLA is simply a failure to explicitly and meticulously implement both object-level and function-level authorization checks within the API. Much of the time, convenience and a false sense of security are at the root of this vulnerability. The desire to move quickly must never override robust authorization mechanisms.

Examples of BFLA in Action

In addition to the example discussed in the previous section, there are quite a few other ways this vulnerability can manifest and be executed. Below, we will look at a few simple example attack scenarios where a BFLA vulnerability is being exploited.

Scenario #1: E-commerce Cart Manipulation

In our first example, imagine an online store where users can buy various items through a checkout. As part of the online stores API, users' shopping carts are managed through an API call that allows items to be added or removed from their cart. This API may look similar to this:

If the API fails to verify that the userID matches the logged-in user, an attacker could modify other shoppers' carts. They could add expensive items, remove items to prevent purchase, or even alter prices at checkout. The result could upset customers and have an impact on operations and revenue.

Scenario #2: IoT Device Sabotage

Next, imagine a smart home system with API controls for various devices. These devices can be manipulated through a POST request and a specific action. An example of such an endpoint might look like this:

If the device associated with the DeviceID is not verified to belong to the user initiating the request and the API doesn't carefully restrict actions based on user roles, unauthorized control becomes possible. If authorization checks aren’t properly implemented, an attacker could remotely turn off critical systems, lock users out of their homes, or create other disruptions within the smart home system.

Scenario #3: Leaky News Feed Manipulation

Lastly, imagine a news aggregator platform that users can use to get a customized news feed based on their preferences. In this case, there is an API to customize a user's news feed through a PATCH operation. This can set which news topics the user wants to see in their feed. Below is an example of what such an endpoint may look like.

If the userID is not validated by ensuring the user who is making the change is, in fact, the user to whom the account belongs, an attacker could inject malicious news sources or remove trusted ones. The result is a manipulated news feed that manipulates the information a user sees. In the most severe cases, this is a potential vector for spreading misinformation.

The key takeaway from these examples is that BFLA vulnerabilities can manifest in various applications, from e-commerce to smart home systems and even news consumption platforms. If an API is used to access, create, or edit data, BFLA vulnerabilities could impact it. This is where prevention becomes an important part of building and maintaining APIs, and we will cover how to protect against BFLA in the next section.

Protecting Against BFLA

With the various ways BFLA can be exploited, securing your APIs against BFLA requires a proactive approach. Core to this is a strategy that embeds authorization into the core of your API development process. Here are key strategies to consider and implement when building APIs to be hardened against

Rethink Object Identifiers and Session Management: Avoid using simple, predictable object identifiers (like sequential numbers). Opt for more complex identifiers, like UUIDs, which are harder to guess. Implementing a session management system that associates object references with specific user sessions and their verified permissions may also make sense.
Meticulous Authorization Checks: Enforce authorization at every API endpoint. Verify the user's identity and roles, and cross-reference their permissions with the data or function they're attempting to access. This should be applied consistently across all business functions within your application.
Input Validation and Sanitization: Rigorously validate and sanitize any data provided by users, especially when used in object identifiers, function calls, or parameters. This defends against injection attacks aimed at subverting API logic.
Principle of Least Privilege: Grant users and system components the absolute minimum permissions required for their roles or tasks. This limits the potential damage if an account or component is compromised.
API Gateways: Centralize authorization mechanisms with an API gateway for a more consistent and scalable security approach. An API gateway can make it easier to implement authorization checks across your API endpoints that proxy through the gateway.
Administrative Function Protection: Ensure that administrative functions (both within administrative controllers and regular controllers) have authorization checks based on user roles and groups.
Regular Testing: Integrate security testing, including DAST solutions specifically designed to find BFLA vulnerabilities, into your development lifecycle to continuously verify the effectiveness of your authorization controls. A combination of automated and manual testing is the best way to ensure endpoints are entirely secure from BFLA attacks.

Based on the last point, it makes sense to explore how StackHawk can help developers implement automated testing using its DAST platform to identify and remedy BFLA vulnerabilities. Next, let's dig into how StackHawk works regarding BFLA detection.

How StackHawk Can Help Detect and Prevent BFLA

When it comes to traditional DAST solutions, BFLA detection is not one of the vulnerabilities they are capable of discovering. Luckily, StackHawk goes beyond traditional DAST solutions by actively testing for BFLA and IDOR vulnerabilities.

At its core, StackHawk is built around empowering developers to take the lead in application security. It provides a suite of tools that make it easy to find, understand, and fix security vulnerabilities before they make it to production. One of the key components of StackHawk is HawkScan, a dynamic application security testing (DAST) tool that scans running applications and APIs to identify security vulnerabilities.

With StackHawk, developers and security teams can:

Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the application code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.

Enabling BFLA Detection in HawkScan

Enabling BFLA detection in StackHawk is easy. Two ways to do this are using the "OpenAPI - Experimental" policy or customizing an existing policy. The "OpenAPI - Experimental" policy allows users to scan for the vulnerabilities outlined in the OWASP API Security Top 10.

To set HawkScan up with the "OpenAPI - Experimental" policy, you will log into StackHawk, go to the Applications screen, and click on the settings link for your application.

Next, on the Settings screen, under HawkScan Settings, click the Applied Policy dropdown and select the "OpenAPI - Experimental" policy.

At this point, you can then run HawkScan and begin detecting potential BFLA vulnerabilities. Another way to do this is to customize an existing policy to scan for BFLA vulnerabilities.

To demonstrate this, we can navigate to the same HawkScan Settings section we looked at above. We will select the "OpenAPI/REST API" policy from the Applied Policy dropdown.

Next, click the Edit Policy button right beside the dropdown.

On the next screen, under the Plugins and Tests section, click on the BFLA entry to enable HawkScan to perform tests for potential BFLA vulnerabilities.

Optionally, if you also want to enable IDOR testing, click the Passive Scan Plugins tab and then select IDOR.

Regardless of how you have enabled BFLA testing in HawkScan, your tests will include testing for potential BFLA vulnerabilities (and IDOR, if you enabled it)!

Conclusion

Understanding BFLA is an essential part of creating secure APIs. However, implementing the necessary authorization mechanisms to protect against these vulnerabilities in real-world applications can be challenging for developers. To ensure that BFLA prevention is applied to API endpoints, organizations should aim to empower developers with the right tools and knowledge to make security a foundational element of API design.

StackHawk does more than just help developers identify potential BFLA vulnerabilities in running applications. It helps bridge the gap between finding and fixing flaws, offering clear explanations and step-by-step remediation advice while integrating seamlessly into existing development workflows. StackHawk’s “shift-left” approach makes API security more accessible and promotes a culture of secure coding practices among developers.

With StackHawk, you can take a proactive approach to finding and fixing BFLA threats before they can hit production. Detect and address vulnerabilities early, safeguarding your APIs and the sensitive data they handle. Sign up for a 14-day free trial of StackHawk and experience the difference it makes in tackling BFLA risks and broader API security challenges outlined in the OWASP API Top 10.

Modern Continuous Security: A Quick Start Guide to Securing Your Software Development Lifecycle

Nicole Jones

Traditional security practices, often siloed and reactive, struggle to keep pace with the rapid development cycles of modern software. This is where the concept of modern continuous security emerges as a game-changer.

What is Modern Continuous Security?

Modern continuous security represents a paradigm shift in how application security is approached. It's a proactive methodology that embeds security practices throughout the entire Software Development Lifecycle (SDLC). Security is no longer viewed as a separate stage tacked onto the end of development; instead, it becomes an integral part of the entire process, woven seamlessly into every step.

Here's a breakdown of the core tenets of modern continuous security:

Integration: Security practices are tightly integrated into the development workflow, fostering collaboration between developers and security professionals.
Automation: Repetitive security tasks are automated, freeing up security personnel to focus on more strategic initiatives.
Early Detection: Security vulnerabilities are identified and addressed as early as possible in the development process, minimizing the cost and effort of remediation.
Continuous Improvement: Security is treated as an ongoing process, with continuous monitoring, feedback, and improvement.

Benefits of Modern Continuous Security

By embracing modern continuous security, organizations can reap a multitude of benefits:

Enhanced Security Posture: Early identification and mitigation of vulnerabilities lead to more secure applications.
Faster Development Cycles: Automating security tasks and integrating security into the development workflow streamline the development process.
Reduced Costs: Fixing vulnerabilities early in the development process is significantly cheaper than remediating them later in the production cycle.
Improved Developer Productivity: By providing clear and actionable security feedback, developers can focus on writing secure code.
Increased Compliance: Continuous security practices help organizations meet regulatory compliance requirements.

Shift Left Security: A Cornerstone of Continuous Security

Shift-left security is a cornerstone principle of modern continuous security. It emphasizes the importance of integrating security practices earlier in the SDLC, ideally as early as the design and planning stages. This doesn't necessarily mean that all security testing should be done upfront. Instead, it advocates for incorporating security considerations throughout the development process.

Here's how adopting a shift-left approach benefits organizations:

Reduced Rework: Identifying and fixing vulnerabilities early on prevents costly rework later in the development cycle.
Improved Code Quality: Security considerations woven into the design phase lead to the development of more secure code from the start.
Faster Time to Market: By addressing security concerns early, organizations can release applications to market faster.

Implementing Continuous Security: A Practical Guide

The transition to a continuous security model requires careful planning and execution. Here are some key steps organizations can take to get started:

Start Small: Don't try to overhaul your entire security process overnight. Begin by implementing small, incremental changes and gradually build momentum.
Build a Security Culture: Foster a culture of security awareness within your organization by providing training and education for developers and other stakeholders.
Select the Right Tools: Invest in security tools that automate tasks, integrate seamlessly with your development workflow, and provide actionable security insights.
Embrace Automation: Automate repetitive security tasks such as code scanning and vulnerability assessments to free up security professionals for more strategic work.
Measure and Monitor: Continuously monitor the effectiveness of your security program and make adjustments as needed.

The Three-Legged Stool of Organizational Change

The successful implementation of continuous security requires a holistic approach that addresses three critical aspects:

People: Invest in training and education programs to equip your team with the knowledge and skills required to implement continuous security practices.
Process: Update your development processes to integrate security considerations throughout the SDLC.
Technology: Implement the right security tools to automate tasks, provide continuous feedback, and enhance overall security posture.

Continuous Security: A Journey, Not a Destination

The journey towards achieving continuous security is an ongoing process, not a one-time event. By adopting a proactive and collaborative approach, organizations can establish a robust security posture that keeps pace with the ever-evolving threat landscape. By integrating security into the fabric of the SDLC, businesses can build more secure applications, accelerate development cycles, and gain a competitive edge in the marketplace.

📺Watch the Webinar

Watch the Secure with StackHawk: A Continuous Approach to Application and API Security webinar recording for a deeper dive into Modern Continuous Security.

What is API Discovery? Everything You Need to Know

StackHawk

APIs are the backbone of the modern digital ecosystem, fueling virtually every application we use. As the software landscape evolves into a more distributed architecture, driven by an extensive array of SaaS and web-based services, the reliance on and traffic to APIs surge. Monitoring API traffic is crucial for detecting anomalies and ensuring security. These interfaces provide developers with crucial advantages, enabling them to tap into pre-existing functionality, speed up the development process, and pioneer innovative solutions.

However, as applications and API portfolios become increasingly complex, maintaining a comprehensive understanding of all existing APIs becomes a significant challenge. APIs can quickly become obscured or forgotten in the sprawling landscape of microservices and interconnected systems.

This lack of visibility creates potential problems. It can lead to redundant development efforts, impede efficient code reuse, and present security risks if hidden or undocumented APIs contain vulnerabilities. This is where API discovery can lend a helping hand.

What Does API Discovery Mean?

In the most basic terms, API discovery is the process of identifying, documenting, and understanding the APIs within a specific environment. As APIs are discovered, they can include those developed internally, those provided by third-party providers, and most crucially, APIs that may be hidden or undocumented.

It makes sense to think of API discovery as creating an up-to-date inventory of all the APIs, or more broadly, digital "connection points" within your systems. The API discovery process involves uncovering details such as:

Endpoints: The URLs that applications use to interact with the API.
Methods: The supported actions (GET, POST, PUT, DELETE, etc.).
Parameters: The data an API can accept and the responses it generates.
Authentication/Authorization: How the API ensures only permitted users or applications can access it.

Why Does API Discovery Matter?

Regarding why API discovery matters, there are many reasons it can be helpful to developers and organizations. Some of these benefits include:

Prevents reinventing the wheel: Discovery can enhance API visibility, revealing existing APIs that solve the problem you're tackling, saving you development time and resources.
Promotes innovation: Knowing what APIs are available unlocks new ideas for applications and integrations.
Simplifies collaboration: A shared API catalog facilitates teamwork by allowing teams to reuse well-defined APIs across projects.

In addition, having a complete API inventory allows organizations to understand which APIs are in use and which are not. If an API is not in use and not maintained, it could present a major security risk that may be unknown if the API wasn't uncovered as part of the discovery process. Whether big or small, if you are using and building APIs, API discovery should be part of your toolkit.

Benefits of API Discovery

API discovery offers numerous benefits that can significantly enhance an organization’s API strategy:

Improved Security: One of the primary advantages of API discovery is the identification of security vulnerabilities. By uncovering all APIs, including shadow and zombie APIs, organizations can address potential security risks, reducing the likelihood of data breaches and cyber attacks.
Enhanced Efficiency: Automated API discovery tools streamline the process of identifying and documenting APIs, saving valuable time and resources. This automation allows developers to focus on building and improving applications rather than manually tracking down APIs.
Better Collaboration: A centralized platform for API discovery fosters collaboration among developers. By providing easy access to a comprehensive API catalog, teams can avoid duplication of effort and leverage existing APIs to build new features and integrations more efficiently.
Increased Innovation: API discovery enables developers to explore and integrate new APIs into their applications. This access to a broader range of APIs drives innovation, allowing organizations to create more sophisticated and interconnected solutions.

What Makes an API Discoverable?

Discovering APIs involves many potential processes, which will be discussed in the next section. However, it's important to first consider some factors that make an API discoverable. Let's examine a few best practices and key facets that contribute to the discoverability of APIs.

Clear and Comprehensive Documentation

Well-written documentation is the cornerstone of API discoverability. It should provide a thorough overview of the API's purpose, how to use it, the different methods it supports, the parameters it accepts, expected responses, potential error codes, and illustrative examples.

Think of this documentation as a user-friendly guidebook for your API. This point also includes following well-known documentation practices, such as creating an OpenAPI Specification (OAS) for your APIs.

Developer Portals

If you want to make an API easily discoverable, exposing it through a developer portal is a great idea. A developer portal is like a central marketplace for your APIs. It lists available APIs, provides powerful search functionality, and often includes features that allow for interactive testing of the APIs, such as Swagger UI. This enables developers to find the APIs they need quickly and experiment with them easily.

Descriptive and Standardized Naming Conventions

Consistent naming conventions for endpoints and parameters significantly aid discoverability. Naming and parameters should be predictable and easily allow developers to understand your API's structure. In addition to ensuring consistency, using meaningful names helps developers infer the functionality of an API even before they have read the complete documentation.

Adherence to Design Standards

Using widely recognized standards such asorcan make your API more intuitive for developers. These standards establish familiar patterns and conventions, which lessen the learning curve for developers who are integrating with and utilizing your API, thus enhancing its discoverability.

These points reflect more of a manual approach to API discovery. In these cases, following the above guidelines allows developers, internal or external, to quickly see what APIs are available and will enable them to use the APIs effectively. But what about discovering hidden APIs? This is where automation can come in handy. Next, let's compare automated and manual API discovery.

Manual vs. Automated API Discovery

As alluded to, there are two primary ways to approach API discovery. Both have particular use cases and methods associated with them. Let's look at the differences between manual and automatic API discovery tools and techniques.

Manual Methods

Manual methods are likely familiar to developers who use APIs. Many of these methods require a technical background and focus on discovering APIs before using them or figuring out which ones are currently used within a codebase. Here are a few ways developers can manually discover available or in-use APIs.

Code Review: Carefully scrutinizing source code to identify how APIs are defined and used.
Network Traffic Analysis: Inspecting network packets to trace communication patterns between applications, revealing API usage. Monitoring API traffic can help in identifying API usage and detecting anomalies.
Referencing Existing Documentation: Reviewing any available API documentation, system architecture diagrams, or developer notes.

These manual techniques can be useful in certain scenarios, but they have limitations. They are often labor-intensive and time-consuming, and they can miss hidden APIs that do not leave obvious traces in the code or network traffic.

Automated Methods

Specialized API discovery tools need to be used for automated methods of API discovery. These can involve tools built into API management platforms, API security platforms, and other tools that support discoverability. These tools are built to scan systems, analyze network patterns, and even probe endpoints to actively uncover APIs. They provide a comprehensive, scalable, and efficient way to identify documented and hidden APIs.

Automated API discovery tools utilize API traffic data to identify calls within the network, contributing to effective management and oversight of API interactions. Other solutions, such as StackHawk, can scan through a code repository to find potential endpoints written within the code.

Quite a few tools are available to fully leverage automated API discovery. Most of them are within API management and security platforms.

API Management Platforms and Gateways: Gateways, such as Kong or Apigee, often include API discovery capabilities because they control traffic and offer insights into API usage.
Security Scanners: Specialized tools such as StackHawk proactively scan for vulnerabilities and map your API endpoints, exposing previously unknown ones.

Automated API discovery tools often offer organizations a significant advantage in maintaining a complete and up-to-date understanding of their API inventory and improving their API security posture. Next, let’s explore the benefits further by looking at what makes API discovery important for modern organizations.

The Importance of API Discovery

API discovery plays a vital role in managing, securing, and maximizing the potential of your API infrastructure. From developers to those involved with the business and compliance aspects of an enterprise, API discovery offers a wide array of benefits.

Security Vulnerability Detection: API discovery lets you gain comprehensive visibility into all the APIs used within your environment. This includes undocumented or forgotten endpoints ("shadow APIs") that are prime targets for attack. Maintaining an accurate API inventory reduces the attack surface and proactively addresses potential BFLA, BOLA, and other vulnerabilities outlined in the OWASP API Top Ten
Improved Compliance: Industries governed by regulations, like healthcare with HIPAA or finance with PCI DSS, frequently have strict requirements for sensitive data access and control. API discovery helps you map the flow of data within your APIs.
Reduced Development Friction: API discovery facilitates faster and more efficient development practices by making it easier for developers to locate and understand existing API functionality, both internal and third-party.
Accelerated Innovation: A catalog of discoverable APIs empowers developers to rapidly create connections between services and enables developers and architects to understand the existing capabilities available within the enterprise. Knowing which APIs are available and understanding their capabilities lead to a faster and easier path towards innovation.
Partnership and Ecosystem Development: API discovery is vital for onboarding partners if you will have third-party users of your APIs. Well-documented and easily discoverable APIs can open business opportunities and enable external developers to use them and collaborate with your organization seamlessly.

Incorporating API discovery into your API development lifecycle and security practices is essential for building robust and secure applications. From a security perspective, one of the biggest downfalls of not using API discovery tools is that hidden APIs may expose vulnerabilities you're unaware of.

Hidden APIs are those that exist within a system but are not cataloged or included in the official documentation. Such APIs can become a significant security and management concern since they may slip through the cracks of security testing and patching.

Shadow APIs

These are unintentionally exposed APIs, often created by developers during testing or for temporary purposes. Shadow APIs might not follow established security standards or documentation practices, leading to potential vulnerabilities being exploited by attackers.

Zombie APIs

These refer to obsolete or deprecated APIs that are meant to be decommissioned but remain active within a system. Poor versioning practices and inadequate tracking of decommissioning processes can result in these APIs continuing to exist among the mix of available APIs, representing potential security risks if they are not properly patched or removed.

Rogue APIs

These APIs are deliberately created and hidden, often with malicious intent. As a backdoor into the system via API, a rogue API may be designed to circumvent security controls or exfiltrate data without authorization.

API Discovery Tools and Platforms

There are various API discovery tools and platforms available to help organizations manage their APIs effectively. These tools can be broadly categorized into automated and manual discovery tools, API management platforms, and IDE plugins.

Automated API Discovery Tools: These tools leverage machine learning and artificial intelligence to automatically discover and document APIs. They can scan systems, analyze network patterns, and probe endpoints to uncover APIs, providing a comprehensive and efficient solution for API discovery.
Manual API Discovery Tools: These tools require manual effort to discover and document APIs. While they can be effective in certain scenarios, they are often labor-intensive and time-consuming compared to automated solutions.
API Management Platforms: These platforms offer a centralized solution for API discovery, management, and security. They often include features such as traffic monitoring, API usage analytics, and security scanning, making them a comprehensive solution for managing APIs.
IDE Plugins: Integrated Development Environment (IDE) plugins provide developers with a seamless experience for API discovery and integration. These plugins can automatically detect APIs within the codebase and provide relevant documentation and usage examples, streamlining the development process.

API discovery tools can help uncover hidden APIs and remedy any security vulnerabilities present within them. The security risks of these APIs can be widespread and leave a massive hole in your security efforts. With that in mind, let's dig a bit further in the next section on those specific security risks.

As mentioned, hidden APIs pose a significant API security challenge because they often exist outside standard security monitoring and governance practices. Even the best security practices are null and void if certain APIs completely escape the umbrella of coverage. By having hidden APIs existing in your portfolio, here are some of the key risks they introduce:

Unpatched Vulnerabilities: Hidden APIs may contain undetected and unpatched vulnerabilities, especially zombie APIs that are no longer actively maintained. This makes them easy targets for attackers.
Expanded Attack Surface: Hidden APIs increase the available attack vectors for malicious actors to exploit. They may discover these APIs through trial and error, code leaks, or automated scanning.
Data Exposure: Poorly secured or undocumented APIs can be gateways for unauthorized data access or leaks. Attackers may use hidden APIs to retrieve sensitive data or manipulate the system unnoticed.
Compliance Violations: Hidden APIs can lead to non-compliance with data privacy regulations such as GDPR, or industry-specific standards. This is because ensuring proper authorization and access controls on undocumented APIs becomes difficult due to minimal oversight.

With these factors in mind, it's easy to see why proactive discovery of hidden APIs is essential. By keeping track of every single API within your organization's API portfolio, you enhance your capabilities for mitigating these risks and maintaining a strong security posture.

Using StackHawk For API Discovery

StackHawk's new API discovery feature enables developers to bundle together a modern DAST platform with the capabilities for continuous API discovery. This innovative tool empowers users to discover API endpoints, including rogue and shadow APIs, thereby bolstering the detection of vulnerabilities throughout your entire API inventory. By allowing users to discover API endpoints previously unknown, such as rogue and shadow APIS, StackHawk's API discovery tool can augment the uncovering of API vulnerabilities across your entire API inventory.

API discovery is an essential process in the modern software landscape. By understanding what APIs exist within your organization, how they work, and whether any hidden risks are lurking, you can streamline development, enhance security, and maximize the value your APIs deliver.

While both manual and automated methods contribute to the process, automated tools provide a considerable advantage in achieving thorough and efficient API discovery, particularly in identifying hidden APIs.

When it comes to building secure APIs, StackHawk helps organizations mitigate the security risks outlined in the OWASP API Top Ten and beyond. Sign up for a free trial today to try out API discovery + DAST in an all-in-one solution.

Essential Cybersecurity Tool Breakdown: The 2024 Essentials for Optimal Protection

StackHawk

With every passing year, the complexity of cyber threats intensifies. With each new threat comes the demand for more sophisticated defenses. This guide is designed to teach you the essential cybersecurity tools that stand as the vanguard against these evolving threats. From network security monitors and web vulnerability scanning to encryption tools, this blog uncovers the critical technologies that cyber security professionals depend on to safeguard our digital realm. You'll learn about the tools and how to strategically select and effectively implement them to enhance your digital defenses.

This year, we saw a significant increase in the demand for cybersecurity tools. With cybercrime costs predicted to soar to $10.5 trillion annually by 2025, the urgency for robust digital protection is crucial. From network security monitoring tools, the critical role of encryption in data protection, web vulnerability scanners and rigorous testing afforded by penetration testing tools, this blog will dive into a handful of solution categories that are necessary for combating cyber threats.

Choosing the right cyber security tool is likened to selecting the most effective armor in battle. It requires a holistic understanding of your organization's unique landscape—considering everything from prevalent industry threats to regulatory compliance. This blog guides you through the selection process, emphasizing the importance of features such as automation, ease of use, and adaptability to new threats. Let's begin by looking at precisely what cybersecurity tools are.

What Are Cyber Security Tools?

A security tool, whether software or hardware, is engineered to detect, thwart, and respond to potential cyber threats and vulnerabilities threatening our digital ecosystems. As the bedrock of cybersecurity, these tools offer the initial barricade against a spectrum of attacks poised to undermine the integrity, confidentiality, and availability of data and systems.

The essence of a security tool lies in its mission to safeguard information and the infrastructures that harbor, process, and communicate this data. Security tools span a diverse array, from the defensive perimeters established by firewalls to surveillance conducted by antivirus programs and intrusion detection systems (IDS). Beyond these, encryption solutions dedicate themselves to protecting data privacy, while security information and event management (SIEM) systems orchestrate real-time security insight and response across the digital landscape.

Moreover, the realm of security tools extends to encompass a variety of operational capabilities essential for comprehensive digital protection. This includes, but is not limited to, vulnerability assessment, which identifies and quantifies security loopholes; patch management, ensuring timely updates to software and systems; endpoint security, guarding every device, including mobile devices, that connects to the network; and access control, which verifies and permits entry to authorized users while barring unauthorized ones. These functionalities can be encapsulated within standalone applications or integrated into multifaceted suites, offering a synergistic approach to cybersecurity.

It's pivotal to recognize their strategic importance in framing our discussion of the myriad types of cybersecurity tools that follow. They are technical solutions and critical components of a holistic security posture designed to protect against the ever-evolving cyber threat landscape. As we explore these tools further, remember that each is a piece of a larger puzzle, working in concert to secure the digital domains upon which modern society increasingly relies.

Types of Cybersecurity Tools

In the intricate and expansive domain of cybersecurity, tools designed to protect our digital environments act as the frontline defense against a spectrum of cyber threats and security flaws. These tools, wielded by dedicated cybersecurity professionals, are pivotal in monitoring network security, encrypting confidential data, identifying vulnerabilities, and simulating cyber-attacks. They are the digital age's superheroes, safeguarding our virtual worlds with unwavering vigilance.

Network Security Monitoring Tools

Network security monitoring tools are the ever-watchful eyes of an organization's digital perimeter. These tools are indispensable for detecting external threats and network security weaknesses and thwarting potential attacks by meticulously analyzing network activities and aggregating essential metrics on network operations. For instance, intrusion detection and prevention systems such as Snort, excel in monitoring network traffic and performing real-time analysis of network protocols to identify unauthorized activities. Meanwhile, platforms like Nagios and Splunk offer comprehensive real-time and retrospective network analysis capabilities, empowering IT teams with alerts on unauthorized activities and providing detailed event reports. Other notable tools in this category include Argus, Nagios, and OSSEC, renowned for their efficacy in detecting external threats to operating systems.

Encryption Tools

Encryption tools are the custodians of digital confidentiality. They are crucial in securing data by transforming readable text into encrypted formats, rendering it inaccessible to unauthorized entities. Solutions like AxCrypt and NordLocker provide robust encryption services, ensuring the safety of sensitive data. Additionally, Tor offers invaluable protection for user identities and locations. GnuPG stands out for its data and communication encryption versatility, offering comprehensive key management functionalities and compatibility across various platforms.

Web Vulnerability Scanners

Web vulnerability scanners act as the cybersecurity landscape's detectives, working to identify security vulnerabilities within web applications to preempt potential exploits. Renowned tools in this domain include Nikto, Nmap, and OWASP’s Zed Attack Proxy (ZAP), each offering unique capabilities in detecting security and network vulnerabilities through meticulous web vulnerability scans.

For more advanced capabilities, StackHawk distinguishes itself with its user-friendly interface, rapid scanning capabilities, and extensive API testing suite, making it an indispensable tool for continuous security monitoring. As a leading solution in Dynamic API and Application Security Testing (DAST), StackHawk empowers developers and security teams to identify and rectify security vulnerabilities in web applications efficiently beyond the capabilities of traditional DAST tools. By adding StackHawk's testing capabilities directly into a CI/CD pipeline, developers can ensure their code is tested upon each pull request. This helps to ensure your team's digital assets remain secure against potential threats as they are being built before any vulnerabilities can hit production.

Penetration Testing Tools

Penetration testing tools are invaluable for evaluating the resilience of cybersecurity defenses. These tools simulate cyber-attacks to identify exploitable vulnerabilities (such as those seen in brute force attacks or cross-site scripting), enabling organizations to fortify their defenses proactively. Metasploit, recognized as a premier penetration testing platform, provides a comprehensive suite of functionalities, including vulnerability scanning and payload execution. Similarly, NMAP is celebrated for its extensive network discovery and security auditing capabilities, which are critical in practical penetration testing efforts.

Of course, the list above does not include every type of security tool since new types of tools are constantly being introduced. That being said, by adopting some of the tools mentioned above, most organizations will be well on their way to creating a production-ready and robust security stack. Want to know more about specific tools to add? Let's check out the top cybersecurity tools for 2024 next!

Essential Cybersecurity Tools for 2024

Are you ready to upgrade your digital defenses? This section dives into cyber security software and tools, revealing the specific solutions you can deploy for network monitoring, encryption, vulnerability scanning, and more. Let's look at some of the top tools to consider for 2024!

Network Security Monitoring

Snort

An open-source intrusion detection and prevention system (IDPS) was created by Cisco and is now supported by a robust community.

Highlights:

Real-time traffic analysis and intrusion detection
Flexible rule-based language for customizing detection
Large community support and extensive documentation

Who should use it? Network administrators and security teams responsible for safeguarding network infrastructure.

Splunk

A powerful platform for log aggregation, analysis, and visualization, offering real-time network security insights.

Highlights:

Collection of log and machine data from diverse sources
Advanced search and correlation capabilities
Customizable dashboards and reporting

Who should use it? IT teams and security operations centers (SOCs) needing comprehensive visibility into network activity.

Encryption

VeraCrypt

A free and open-source encryption tool, considered a successor to TrueCrypt, offering advanced security features.

Highlights:

On-the-fly encryption for files, partitions, and entire drives
Plausible deniability and hidden volumes for enhanced security
Cross-platform compatibility

Who should use it? Individuals and businesses seeking robust data encryption for sensitive information.

NordLocker

A cloud-based encryption solution from the makers of NordVPN, providing user-friendly secure file storage and sharing.

Highlights:

Zero-knowledge encryption (only you have the keys)
Easy drag-and-drop file encryption
Secure collaboration features

Who should use it? Individuals and teams needing cloud-based encryption with a focus on usability and collaboration.

Web Vulnerability Scanning

StackHawk

A developer-focused DAST (Dynamic Application Security Testing) platform designed for modern development pipelines.

Highlights:

Seamless integration into CI/CD pipelines
Fast and accurate vulnerability scans
Prioritization and actionable remediation guidance

Who should use it? AppSec and development teams looking to integrate security testing directly into their build processes.

Snyk

A developer-centric security platform encompassing both SAST (Static Application Security Testing) and open-source dependency scanning.

Highlights:

Code analysis during development for early vulnerability detection
Identification of vulnerabilities in open-source libraries
Integration into IDEs and CI/CD pipelines for seamless testing

Who should use it? Developers and DevSecOps teams seeking to prioritize security within their software development processes.

Penetration Testing

Metasploit Framework Metasploit is an open-source penetration testing platform with a vast library of exploits and payloads.

Highlights:

Modular architecture for customizing attacks
Development and execution of custom exploits
Large community and extensive resources

Who should use it? Experienced penetration testers and ethical hackers

Choosing the Right Cybersecurity Tool for Your Needs

With so many available tools, selecting the right ones can be challenging. A strategic approach is crucial, considering unique risks, industry-specific threats, compliance requirements, and your organization's goals. Let's explore the essential factors guiding your decision when adopting new security tools.

Know Your Enemy: Conduct a Risk Assessment

Begin by identifying your most valuable assets and the specific vulnerabilities they may face. Consider prevalent threats within your industry and understand the regulatory landscape you must navigate (e.g., HIPAA for healthcare, PCI-DSS for payment processing).

Match the Tool to the Task: Evaluate Features & Functionality

Does the tool address the specific risks you've identified? Consider its core features, the level of automation it offers, and whether it seamlessly integrates with your existing technology stack.

Usability is Key: Assess Ease of Use and Adoption

A tool with a steep learning curve can lead to underutilization or misconfiguration. Prioritize intuitive tools your team can quickly adopt and maintain, minimizing friction and maximizing security gains.

Investigate the Source: Vendor Reputation

Choose vendors with a proven track record in security, responsive support, and a commitment to continuous improvement. Their reputation is an indicator of the tool's reliability and trustworthiness.

Think Ahead: Adaptability to Evolving Threats

The cybersecurity landscape is changing rapidly. Does the tool have a robust roadmap for updates and the ability to adapt to emerging threats? Choosing future-proof solutions ensures your investment continues to protect you over time.

The Bottom Line: Cost and ROI

Factor in the total cost of ownership, including licensing, support, deployment, and training. Analyze the potential gains regarding risk reduction, regulatory compliance, and the impact on your security posture.

Considering these factors, organizations can guarantee that they have a good start on building a robust security stack that keeps up with the demands of modern applications. The most significant point is to remember that security is very custom and personal and depends on the organization and the application's needs.

Staying Ahead of Security Threats with StackHawk

When looking for the best cybersecurity tools to empower developers, StackHawk is there to help teams take a proactive stance on API and application security by "shifting left". StackHawk’s DAST solution is not just about detecting vulnerabilities; it's an engine for continuous security improvement. With its developer-first approach, StackHawk places the power of security in the hands of those who know the intricacies of the code—those who build it.

StackHawk’s platform is engineered to integrate seamlessly into your development workflow, making security testing a natural part of the process rather than an afterthought. It automates the discovery of security bugs, allowing developers to find and fix issues as they occur in real-time. This streamlines the path to production, ensuring security keeps pace with rapid deployment cycles by allowing users to embed StackHawk's capabilities into their CI/CD flows. As a result, it bolsters security and aligns with agile methodologies and DevOps practices.

Being easy to configure and deploy, StackHawk ensures that getting started with security testing is a hassle-free experience. Its user-friendly interface and detailed documentation mean that even teams new to DAST can begin fortifying their applications with minimal onboarding time. By choosing StackHawk, you're not just choosing a security tool—you're adopting a security partner that scales with your needs, simplifies compliance, and offers clear insights with actionable data to secure your applications against the latest threats.

Summary

As we wrap up this comprehensive journey through the essential cybersecurity tools for 2024, it's clear that the stakes in digital security have never been higher. In an era where cyber threats escalate, and technological advancements surge rapidly, the cybersecurity tools we've examined are indispensable elements of your digital defense arsenal. Organizations can address vulnerabilities head-on by understanding and implementing SAST, DAST, IAST, and other pivotal security solutions, ensuring resilience against current and future cyber threats.

The cybersecurity landscape is a battleground where only the best-armed survive and thrive. Tools like StackHawk's DAST platform offer a glimpse into the future of cybersecurity, where automation, integration, and developer-centric solutions lead the charge in securing our digital frontiers. StackHawk's ease of use and deep integration into the CI/CD pipeline enables teams to seamlessly incorporate security into their development process, making it an indispensable ally for vulnerability detection and response.

Don't let the complexity of cybersecurity deter you. Embrace it with StackHawk and turn it into your competitive edge. Take the step today to experience the power of proactive security by trying out StackHawk. Start your free trial and equip your team with the capabilities to detect, analyze, and remediate security vulnerabilities with confidence and precision.

What is An API: A Complete Guide

StackHawk

Regardless of your involvement in technology, you've likely come across the term "API," also known as Application Programming Interface – a critical intermediary enabling different computer programs to interact and share information easily. Some analogies liken APIs to the “waiter example,” in which the waiter is the API, and serves as the intermediary passing information (or a note) between you and a friend sitting at two different tables in a restaurant.

In reality, APIs are much more powerful than the analogy of the waiter and are responsible for powering the majority of applications and technology we rely on daily. This blog post will dive into the world of APIs, highlight what they are, how they work, and most importantly, why you should care.

What is an API?

Before diving into the details, let's clarify a fundamental question: What exactly is an API? Simply put, an API is the framework that enables systems to communicate. It establishes a standard set of commands and protocols that enable different entities to communicate with each other, despite their inherent differences.

It's a bit like the rules of a game - they define how all the players interact and, in many ways, establish the boundaries within which the players refer to each other. In the same way, APIs set the form and boundaries of software communication, allowing us to share server data, perform tasks, and work collectively and collaboratively.

How do APIs Work?

APIs communicate in a process similar to having a conversation.

Making the Call

Just as you might call a friend to suggest grabbing coffee, an app makes an API call to initiate an interaction. This is the digital equivalent of reaching out to start a conversation.

Sending a Request

Once the call is connected, you ask your friend, "Do you want some coffee?" In the realm of APIs, this translates into a "request." The requesting app specifies its needs in a universally recognized format, leveraging the HTTP (Hypertext Transfer Protocol) standard that web APIs use.

Receiving a Response

Just like a friend responds to your coffee invite, the targeted app or API endpoint replies with an API response. This "response" could affirm the action, deny the request, or inform you of an error, much like a friend's confirmation, refusal, or suggestion to meet elsewhere.

Endpoints

Although this is a very simple example, it outlines the basics of an API call and the request and response that are part of the overall interaction. In the above example, however, you need a phone number to make this call - in the world of APIs, this is referred to as an endpoint.

API endpoints are crucial in the process of different online services communicating with each other. They're essentially web addresses with a specific action attached to them—for instance, "GET userID" includes an action, "GET", and an object to act upon, "userID."

Each endpoint is a unique address that guides the data flow to the right place within an API. These generally look just like web URLs we use in the browser, since the data you receive back in your browser can also come from an API.

Data Flows Through APIs

For example, if you’re using any one of several web applications to check the weather or order some food, the app sends a request to the service’s API endpoint. This endpoint knows how to fetch the data for your specific query, and often provides additional context or references for you to get more contextual information. Then, it sends this data back to the app, which displays the information to you. Endpoints ensure that requests for data or actions reach the exact location in the system that can handle them, making the interaction between different services seamless and efficient.

APIs extend beyond the internet, existing in your computers, smart medical devices, and even in your Bluetooth-connected toothbrush. They interact with various data structures and software components in unexpected ways, and often, these systems lack a Graphical User Interface (GUI). APIs are remarkably widespread and versatile.

Key Concepts of APIs

Web APIs use a specific set of concepts to define how different applications communicate, similar to how we use text messages to send messages back and forth. This conversation between apps occurs through a simple yet effective process called a client-server model, which can be broken down as follows:

The Client

Imagine this as one app that initiates the conversation, similar to how you might text a friend to ask a question. The API client is an app that makes a request when it needs something. For instance, when you use a weather app on your phone (the client) to check the forecast, you're essentially asking it to find and display the latest weather information.

The Server

On the other side of this conversation is the server, like the friend who receives your text and responds. The server is another application that waits for requests. When it receives one, like the weather app on your phone asking for the latest forecast, it knows how to fetch that information or perform the needed action. Once it has the information, the server sends it back to the client app, which presents the results to you.

The Language

A common language is necessary for these digital interactions across the client-server architecture to be effective. Web APIs utilize HTTP, the standard web protocol that facilitates these exchanges. Think of HTTP as the grammar rules ensuring apps communicate effectively, irrespective of its origin.

HTTP headers specify the message's format, commonly in JSON (JavaScript Object Notation) or XML (Extensible Markup Language) sent to the web API, and how responses should be formatted. With its user-friendly and concise structure, JSON is ideal for straightforward data sharing. In contrast, XML offers a more detailed, hierarchical approach suitable for complex data exchanges.

RESTful APIs

The REST approach to APIs, first proposed by Roy Fielding in his doctoral dissertation, has become a popular framework for organizing services. Although other models like SOAP and gRPC are available, REST is prevalent in web APIs and often serves as the initial entry point for many beginners.

REST APIs, to be considered RESTful, must follow several key principles, simplified as follows:

Use a client-server model;
Adopt "stateless" communication, where each HTTP request is independent;
Utilize standard HTTP methods like GET, POST, PUT, DELETE, etc., to interact with resources.
Allow caching for data performance; and
Provides hypermedia, facilitating client-server decoupling and enabling iterative, independent development.

Each REST API request is self-contained, carrying all information necessary for completion without depending on prior requests.

REST APIs are versatile, interacting with multiple data formats, including JSON, XML, and more:

Plain Text: Simple and direct, perfect for basic messaging.
HTML: The foundation of web pages, enabling rich text formatting.
YAML: A human-friendly data format ideal for configuration files.

The flexibility of REST APIs empowers developers to select the most fitting communication method, enhancing app interaction efficiency.

Why Are APIs Important?

If you’re working with any modern software or building it, APIs are likely a crucial piece of application functionality. They connect various internal systems, such as linking customer service platforms with marketing tools or integrating project management applications with time-tracking services, to improve collaboration. Everything from executing complex application logic to simple CRUD (Create, Read, Update, and Delete) operations, most applications can’t function without some sort of API usage.

Beyond internal use, APIs allow companies to expand their offerings by integrating with external partners' web services, enhancing their products with new features or data for an improved customer experience.

While APIs come in many forms, including those that operate systems and devices, web APIs are particularly vital to the tech ecosystem. They enable the creation of diverse online systems, from weather updates and online shopping to bill payments, underpinning nearly all online activities.

Types of APIs

Depending on who will use an API or have access to it, there are some sub-types that APIs can fall into.

By Audience and Access Level

APIs can be broadly categorized based on who can access them and how they're used based on the following categories:

Private APIs are the backbone of internal operations within companies, safeguarding sensitive data while ensuring seamless inter-departmental communication.

Partner APIs open doors to strategic business-to-business (B2B) collaborations, offering a secure yet flexible way for companies to integrate and leverage each other's resources and capabilities.

Public APIs democratize company services access, inviting external developers to innovate and develop applications that enhance or complement the original platform. This broad access can amplify a company's influence and potentially unlock new revenue streams.

By Use Case

On top of the categories above, there are also some other descriptors for APIs to be aware of and what they mean. These include the following:

Open APIs stand out for their unrestricted access, fueling innovation across the digital ecosystem by enabling developers worldwide to create and expand upon existing platforms.

Internal APIs, synonymous with private APIs, optimize organizational efficiency by facilitating the smooth flow of information and functionalities within a company.

Composite APIs efficiently bundle multiple API requests into one, minimizing the number of calls made and accelerating processes that depend on data from numerous sources. Composite APIs are especially useful for streamlining client and web server interactions, reducing the number of round-trip calls needed to perform related operations.

Advantages of APIs

APIs are incredibly powerful, but they're also quite malleable. While RESTful APIs are the most common APIs in the web space for end users, the web is actually filled with many different kinds of APIs that provide unique advantages for specific use cases:

REST (Representational State Transfer)

RESTful APIs utilize HTTP methods in a flexible, stateless model, ideal for building scalable web services. They adhere to RESTful architectural constraints, simplifying communication over the web and allowing for individual development outside of strict confines.

SOAP (Simple Object Access Protocol)

SOAP APIs prioritize security and standardized protocols, employing XML to ensure robust data exchange across diverse platforms. This makes them a preferred choice for enterprise-level applications, especially legacy ones. The ability to control this exchange and audit over time makes it popular for banking and other regulated industries.

GraphQL

Revolutionizes data retrieval by allowing clients to specify precisely what information they need using a graph query language, significantly reducing inefficiencies associated with data over-fetching or under-fetching.

gRPC

Google RPC, or Remote Procedure Call, APIs focus on high-efficiency communication, which is particularly beneficial in microservices architectures by enabling quick and compact binary data exchange.

WebSocket

WebSocket APIs provide a continuous connection for real-time interactions, enhancing experiences in applications that demand instant updates, like messaging apps or online gaming.

Webhooks

These APIs provide another method to access server data, offering a mechanism for apps to automatically notify each other about events. This enables responsive and synchronous workflows across different services, helping remote APIs connect software systems that may not have a live user directly on the other end requesting the exact data as specified.

Common Use Cases

APIs are integral to applications in diverse fields like mapping, weather forecasting, and social media, enhancing our daily digital interactions. They allow mapping apps to display maps and traffic updates, and travel sites to access real-time hotel and flight data. This concept, part of the API economy, involves initially offering free APIs and later monetizing them. API marketplaces further this economy by enabling developers to buy and sell APIs, fostering new business partnerships and innovative services.

Let's take a quick look at some common APIs that are used extensively on the web and in mobile applications.

Google Maps API

The Google Maps API is a perfect example of an API that enhances application functionality. It allows developers to incorporate customized maps into websites or applications using Google’s geographic data, enabling features like real-time traffic updates, street view, and detailed location information.

Industries such as travel and delivery services utilize the Google Maps API to enhance their services. Google Maps API can help with:

Itinerary creation for travelers
Display routes for deliveries
Offer real-time map updates for the most current map data.

These features make the Google Maps API a valuable tool for businesses in these industries.

WeatherAPI

The WeatherAPI is another example of how APIs provide real-time data in applications. It provides real-time weather data that can be used in websites and applications to display current conditions and weather forecasts. This information can be crucial in various contexts, from planning a picnic to scheduling a flight.

Social Media APIs

Social media giants like Facebook and Twitter provide APIs that let third-party apps seamlessly integrate their services, offering features such as single sign-on with social media credentials, which simplifies user experience by streamlining logins and reducing password overload.

API Trends and Looking to the Future

As APIs evolve to match modern users' changing needs, emerging trends are becoming important for both users and service providers to consider.

Authentication and Authorization Focus

With increasing threats to the internet and World Wide Web, security has become a crucial concern.

Securing an API involves establishing strong authentication methods right from the start. This typically includes utilizing an API key and deploying authentication tokens, which are crucial in ensuring secure and legitimate communication. An API key acts as a unique password for applications, enabling them to authenticate their identity with each request they make. This key, generally obtained and managed via the API provider’s developer portal, is a fundamental access control layer by granting permissions based on predefined rules.

Authentication tokens take security a step further. They validate access requests and manage user sessions or specific privileges. These tokens are generated following a successful login, offering a more dynamic and secure approach by detailing more granular permissions aligned with the user's role. This method significantly boosts security by facilitating temporary and revocable access, ensuring each session is secure and specific to the user’s access rights.

API endpoints act as critical gatekeepers within this security infrastructure, controlling access to the API’s underlying functionalities and data. Endpoints are essential in protecting the API from unauthorized entry by ensuring that only authorized users or applications can access sensitive information or perform specific actions.

Fine-Grained Access Control

Many providers have shifted from a top-down security approach to one that is significantly more granular, allowing for greater flexibility while improving overall security outcomes. Effective access control is foundational to API security and involves:

Establishing user roles and permissions, determining what data and functionality are accessible to different users.
Implementing detailed access rules using standards like OAuth 2.0, OpenID Connect, and JSON Web Tokens (JWT). These protocols offer secure, token-based authentication mechanisms, enabling web APIs to grant access based on verifiable credentials.

In contrast to API keys, which have a broad and static scope, tokens offer a dynamic and revocable means of access control. Their temporary nature and specific scope make them more secure, minimizing potential data exposure risks.

By adopting these strategies—using API keys and tokens for authentication, implementing API Gateways for centralized management, and applying granular access control—developers can greatly enhance the security and integrity of their APIs, safeguarding both their data and users.

Enhanced Integration and Collaboration

API integration, vital to contemporary software development, facilitates seamless system interaction and data exchange. In a landscape where APIs must interoperate extensively, developers face unique challenges.

Maintaining up-to-date API integration requires careful management of API versions, secure authentication processes, proficient error handling, and scalability planning. Automated testing and monitoring tools are critical for sustaining API performance and reliability. Compliance with provider-imposed rate limits is essential to prevent disruptions and maintain dependable user services.

Better Documentation

The increased emphasis on documentation reflects that simply having a great API isn't sufficient; modern web APIs must be accompanied by detailed documentation, which includes references, tutorials, and guides on functions, classes, and usage, to effectively serve developers. Best documentation practices involve following API design standards and employing tools like OpenAPI for specifications. Tools such as Swagger and Postman facilitate creating various documentation types, from static to interactive. Industry leaders like Stripe and Twilio, known for their comprehensive and accessible API documentation, set valuable benchmarks to emulate.

Leveraging API Libraries and SDKs

API libraries and SDKs are crucial for simplifying API development and integration, offering tools and frameworks that streamline the process. From Apple’s iOS SDKs for mobile app development to Microsoft's .NET SDK for enterprise applications, these resources allow developers to easily incorporate API functionalities into their projects.

The key to effective API integration lies in utilizing these tools, maintaining clear documentation, and leveraging libraries and SDKs to ease development. This approach ensures smooth and efficient API integration, whether integrating with another API or enhancing the accessibility of your own.

More API Testing - and More API Testing Tools

The complexity of modern API architectures, which enable extensive data connections and retrieval, has emphasized the need for enhanced API testing. This necessity is highlighted by the "shift security left" approach, advocating for improved security measures early in the development process through robust API management tools. Consequently, security has transitioned from a desirable add-on to a critical component of development.

Conclusion

APIs are indispensable in crafting the interconnected digital experiences we've come to expect. Their role in modern software development extends from simplifying complex interactions between systems to enabling instantaneous data sharing and enhancing user engagement across platforms. As digital solutions evolve, the strategic implementation of APIs will remain a key driver in developing innovative, efficient, and user-centric applications. Remember, each time you enjoy a frictionless digital service, multiple APIs are likely working tirelessly behind the scenes.

If you’re building and working with APIs, StackHawk can help you to boost your API's security before it reaches your customers.

StackHawk's API Security Platform helps organizations discover unknown APIs with API Discovery, and bring them under test to maintain a continuously secure approach with Dynamic Application Security Testing (DAST). By bridging the gap between developers and AppSec teams, StackHawk offers the best way for developers to test their APIs as they build them, uncovering potential security issues, and offering actionable solutions to fix, while giving AppSec teams the insights into unknown APIs, frequency of commits, and oversight into their security program.

Interested in improving your API's security from the get-go? Sign up today for a free trial and begin your API build journey with security in mind.

Finding and Fixing BOLA Vulnerabilities in NodeJS With StackHawk

StackHawk

For developers striving to build secure APIs, Insecure Direct Object References (IDOR) stand out as a critical vulnerability to look for. As outlined in the OWASP API Security Top 10, this vulnerability can lead to unauthorized access and manipulation of data, leading to disastrous consequences. Broken Object Level Authorization (BOLA) vulnerabilities arise when applications fail to enforce adequate authorization checks for accessing objects or resources. This flaw enables attackers to exploit user-supplied inputs, like URL parameters, to access or manipulate objects they shouldn't, such as files or database records. Without proper authorization validation, attackers can bypass restrictions, potentially leading to unauthorized data access and system breaches.

In this blog, we will examine the details surrounding BOLA, including what it is, the root causes of BOLA vulnerabilities, and how to identify BOLA vulnerabilities in your API code. We will then use StackHawk to scan a vulnerable Node application and detect a BOLA vulnerability in one of the endpoints. Lastly, we will show the steps required to fix the vulnerability and retest the code to ensure it has been resolved. Let’s start by taking a deeper look at what BOLA is.

What is Broken Object Level Authorization (BOLA)?

Broken Object Level Authorization (BOLA), previously known as Insecure Direct Object Reference (IDOR), remains a top threat to API security. This vulnerability emerges when an API lacks rigorous controls, preventing users from accessing resources or data outside their intended permissions.

Object-level authorization defines an application's rules for what actions users can take on specific pieces of data. A healthcare app, for example, should limit patient access to only their medical records. BOLA vulnerabilities arise when these controls are inadequate or absent. This might include an API using easily guessable object identifiers (think customer IDs) or not verifying if a user's request aligns with their actual permissions.

BOLA attacks tend to follow a simple pattern. The attacker first studies API traffic to identify how objects are referenced (e.g., /users/{userID} or /orders/{orderID}). They'll then try to modify these identifiers, hoping to reach data belonging to unauthorized users. An attacker could view, change, or even delete sensitive information if authorization checks are weak. In severe cases, complete and unauthorized control over objects might be possible.

BOLA's prevalence and danger come from its ease of exploit (attackers don't always need deep technical knowledge) and the difficulty traditional security scanners have identifying these flaws. The fallout of a successful BOLA attack can include privacy violations, compromised accounts, financial theft, or even disruption of API-controlled systems.

What is The Difference Between BOLA and Insecure Direct Object Reference (IDOR)?

You may come across both "BOLA" and "IDOR" when discussing this type of API vulnerability. While there's a lot of overlap between the terms, understanding their subtle distinction is important. Insecure Direct Object Reference (IDOR) is the older phrasing, highlighting situations where an API reveals internal object references or identifiers that are easy for an attacker to manipulate. Imagine a URL structure like /api/customers/{customerID}; an attacker could try substituting different customerIDs to access data they shouldn't.

The shift to the term Broken Object Level Authorization (BOLA) reflects a broader understanding of the problem. The core issue isn't solely about the type of reference used but rather a breakdown in authorization logic. This could mean the API relies on predictable object identifiers or fails to thoroughly check if the user making a request has legitimate ownership or permissions to interact with the object in question.

To recap, IDOR vulnerabilities all fall under the umbrella of BOLA. However, not every BOLA vulnerability necessarily involves a directly exposed, easily manipulated object reference. The fundamental problem always centers around the API incorrectly implementing object-level authorization checks.

What is The Root Cause of BOLA?

BOLA vulnerabilities arise from development practices prioritizing ease of use over building strong authorization into the API's logic. Here's a breakdown of the main reasons this happens:

Over-reliance on Object Identifiers

When APIs directly reference objects using easily guessed patterns (sequential numbers, predictable text, etc.), it's an open invitation for attackers. A URL like /api/documents/{documentID} makes it tempting for attackers to try different documentIDs and potentially find things they shouldn't.

Lack of Ownership and Permission Verification

APIs must consistently check that the user making the request owns the object they're targeting or has the right permissions to work with it. This can't be a one-time check; it needs to be done with each request.

Blind Trust in User Input

Anything sent to the API by a user, including object identifiers, must be treated with caution. Thorough input validation is also necessary to prevent attackers from sneaking in values designed to break API logic.

Insufficient Focus on Authorization

Development pressure can lead to inconsistent or overlooked authorization for some API actions. Strong authorization must be baked into the design.

The Fallacy of Obscurity

Using hard-to-guess identifiers ( like long UUIDs ) can create a false sense of security. Attackers are resourceful; if the only protection is a 'tricky' identifier, they'll likely find a way around it.

Ultimately, BOLA comes down to not building strong, object-level authorization checks directly into the API's code. Convenience and 'hiding' things can never replace a well-designed authorization system.

Preventing Broken Object Level Authorization (BOLA) Vulnerabilities

Since BOLA vulnerabilities happen when an application doesn't have strong enough checks before allowing access to objects. To combat this, you need a thorough approach to building and maintaining your APIs, emphasizing secure design, robust authorization, and constant vigilance. Here are a few ways to effectively reduce your BOLA risk:

Core Practices

Enforce Strong Authorization Checks: Every time a user tries to do something, verify they have the right permissions. This has to be baked into the heart of your APIs.
Consider Attribute-Based Access Control (ABAC): While role-based systems (RBAC) work well in many cases, ABAC lets you be more specific. ABAC policies can consider the user, the target object, and the action – ideal for complex applications with many moving parts.
Use Scoped Access Tokens: If you use tokens (like OAuth or JWTs), limit what those tokens can access, such as permission to only perform specific CRUD operations. This lessens the impact if a token is stolen or misused.

Proactive Measures

Regular Security Audits and Penetration Testing: Use outside experts to thoroughly test your application and platforms like StackHawk, which can actively test for vulnerabilities like BOLA. Using these teams and tools may find BOLA vulnerabilities your internal teams missed.
Educate Developers: Teach your development team how to code with security in mind and how to spot common vulnerabilities like BOLA.
Use Secure Frameworks and Libraries: Tools that encourage secure practices and include pre-built authorization features can save time and reduce errors.
Adopt a Zero Trust Mindset: Never assume a request is safe, even if it seems to be from a legitimate user inside your network. Verify the authorization of every request.

By following these guidelines, you'll significantly reduce your application's risk of BOLA vulnerabilities, ensuring users can only access what they're supposed to. Now, let’s put this into practice by looking at a vulnerable NodeJS application and use StackHawk to identify the BOLA vulnerability and help us verify that the fix we will implement successfully remediates the issue.

Detecting and Fixing BOLA Vulnerabilities in NodeJS

Building The Vulnerable Endpoint

Below is an example of a simple Node.js API with a BOLA vulnerability. This API allows users to access user data based on a user ID passed in the URL. However, it doesn't perform any checks to ensure that the user making the request can access or modify the data for that user ID. This demonstrates a BOLA vulnerability in its most simple form.

Please note: This is an intentionally vulnerable API for demonstration purposes. Do not use this code in a real application as it is not production-ready.

To run this app, first, ensure you have Node.js installed. Then, create a new directory for your project, ours is named “bola-api-example”, and initialize the directory by running

npm init

You'll also need to install Express, a popular web framework for Node.js, as well as a few other dependencies we will use in the project. You’ll do this by running the following npm command:

npm install express body-parser sqlite3 express-oas-generator jsonwebtoken

Note: The jsonwebtoken dependency will be used later, but we will install it now for ease.

Now, in the root of the project we just created, create a file named app.js and add the following code:

Let’s run through a quick breakdown of the code above that shows how to create a simple web server using Node.js, Express.js, SQLite3, and automated OpenAPI documentation creation with express-oas-generator. The code provides a REST API for accessing user information stored in an SQLite database, all running in memory for simplicity and demonstration purposes. Here's a breakdown of the key components and actions within the code:

At the beginning (const app = express();), an Express application is initialized, which serves as the backbone for creating API endpoints. Then, we create the configuration for OpenAPI Documentation with express-oas-generator. The expressOasGenerator.init(app, ...); section initializes the automatic generation of OpenAPI documentation for the Express app. This documentation is dynamically adjusted based on the defined API paths. In this case, we also explicitly modify the API documentation to detail the parameters expected by the /users/{id} endpoint.

Next, we configure the Express app to use body-parser middleware, allowing the app to parse JSON request bodies. This is essential for endpoints that accept data (e.g., POST requests), although we don’t directly use it in the code since we only have a GET endpoint defined.

After this, The code sets up an SQLite database in memory (const db = new sqlite3.Database(':memory:');). This in-memory database is temporary and ideal for demonstration, as it doesn't require us to connect to an external database engine. Within db.serialize(...), a table named users is created, and three example user records are inserted into this table. This sets up the initial data state with which the API will interact.

Then we define the API Endpoint to Fetch User Data. The route app.get('/users/:id', ...) defines an API endpoint that allows clients to fetch user data by ID using a parameterized SQL query to prevent SQL injection.

Finally, we initialize the application, which listens to incoming requests on a specified port (const PORT = 4000;). This makes the API accessible to clients, and a console log message confirms the server's successful launch.

Running The Code

Now that our code is complete, it’s time to run the application and bring up our API. To run your API, run the following command in a terminal pointed to the root of your project:

node app.js

Once the application is up and running, you’ll notice that the GET /user/:id endpoint allows anyone to retrieve user data by simply specifying a user ID in the URL.No authentication or authorization checks are performed, meaning any user can access or modify any other user's data. This is a classic example of BOLA vulnerability.

Detecting The Vulnerability With StackHawk and HawkScan

If you’re logging into an existing StackHawk account, from the applications page, you’ll click Add an App -> Create Custom App

Enabling BOLA Detection in HawkScan

After creating the app in StackHawk, we need to do a few more steps to enable BOLA (and IDOR) detection in StackHawk. Two ways to do this are using the "OpenAPI - Experimental" policy or customizing an existing policy. The "OpenAPI - Experimental" policy allows users to scan for the vulnerabilities outlined in the OWASP API Security Top 10.

To set HawkScan up with the "OpenAPI - Experimental" policy, you will log into StackHawk, go to the Applications screen, and click on the settings link for your application.

Next, on the Settings screen, under HawkScan Settings, click the Applied Policy dropdown and select the "OpenAPI - Experimental" policy.

At this point, you can then run HawkScan and begin detecting potential BOLA vulnerabilities. Of course, another way to do this is to simply customize an existing policy to scan for BOLA/IDOR vulnerabilities. To show how this can be done, we can navigate to the same HawkScan Settings section that we looked at above. From here, we will select the "OpenAPI/REST API" policy from the Applied Policy dropdown.

Next, click the Edit Policy button right beside the dropdown.

On the next screen, under the Plugins and Tests section, click on the BOLA entry to enable HawkScan to execute tests for potential BOLA vulnerabilities.

If you also want to enable IDOR testing, you can click on the Passive Scan Plugins tab and then select IDOR.

Now, with our Application set up in StackHawk, our stackhawk.xml added to the root of our API project, and BOLA/IDOR detection enabled, we can finally test our application.

Run HawkScan

In order to test our application, in a terminal pointing to the root of our project, we will run HawkScan using the following command:

hawk scan

After running the command, the tests should begin to execute in the terminal.

This will run tests against our API based on the OpenAPI spec using the OpenAPI Spider provided by StackHawk.

Explore The Initial Findings

Once the tests are complete, the terminal will contain some information about any vulnerabilities found. Below, we can see that it has identified the BOLA vulnerability that we introduced in the code. To explore this further, we will click on the test link at the bottom of the output. This will take us into the StackHawk platform to explore further.

After clicking on the link, we can now see the test results nicely formatted. Next, we will click on the Possible Broken Object-Level Authorization (BOLA) entry.

Fixing The BOLA Vulnerability

To fix the BOLA vulnerability in the Node.js API, you must implement authentication and authorization checks. This will ensure that users can only access and modify their own data. For simplicity, I'll demonstrate a basic version of these checks. In a real-world application, you'd likely use more robust authentication and authorization mechanisms and platforms, such as Auth0 or Okta, to control access and handle credential creation.

To remedy our BOLA vulnerability, update your app.js with the following code:

The updated code introduces the jsonwebtoken package to implement JWT-based authentication and authorization. This is a significant enhancement over the original code, which did not include any form of user authentication or authorization. To use this, you’ll also see the addition of the constant JWT_SECRET defined, which is used to sign and verify JWTs. This key is essential for the security of the token-based system, ensuring that tokens are valid and issued by the server. Of course, the key is extremely simple since it is just for demonstration purposes. In a production system, you’ll want to have a longer and complex key that is not directly defined in the code!

Next, the authorize middleware function is defined which checks if the authenticated user (decoded from the JWT) is authorized to access the requested user data. The comparison is made using the sub claim from the JWT against the user ID from the request parameters. The /users/:id endpoint is now protected by both the authenticateJWT and authorize middleware, arranged in an array. This sequential middleware arrangement ensures that every request to this endpoint is first authenticated and then authorized, a common pattern to enforce security on API endpoints.

Once the code has been updated on your side, you can stop the currently running server (by using ctrl + C in the terminal) and restart it with the new code using:

node app.js

The app should now be up and running with the updated code!

Confirm the fix!

With the latest code, users must send a JWT along with their request in the Authorization header. The code will then extract the sub field to ensure that the sub value (the user's ID) matches the ID of the record they are trying to access. In the JWT.io debugger, this is how such a token would look:

Now, let’s confirm the fix in StackHawk. To do this, we will click the Rescan Findings button back in StackHawk.

Then, we will see a modal containing the “hawk rescan” command that includes the correct Scan ID. You’ll run this command in the same terminal where you ran the initial set of tests.

In the output, you will again see any vulnerabilities found in the scan. In this case, you’ll see that the BOLA vulnerability is no longer showing. Clicking on the link at the bottom of the terminal output, you can confirm that the BOLA vulnerability has now been added to the Fixed Findings from Previous Scan, confirming that the vulnerability has been successfully fixed and has passed any vulnerability tests.

With that, we’ve successfully remedied and retested our API to ensure its safety from potential BOLA attacks. Please remember that the code above is for demonstration purposes and that adding robust, production-grade authorization to an API endpoint is much more involved than we implemented above. Using an API gateway and identity provider, such as Auth0, is one of the best ways to prevent BOLA and secure your APIs from unauthorized use.

Why StackHawk?

When it comes to preventing vulnerabilities, such as BOLA, StackHawk offers a comprehensive platform for developers to secure their applications and APIs. StackHawk is a modern, powerful DAST tool designed for developers to integrate application security testing seamlessly into their software development lifecycle. It is not just another security tool; it's a developer-first platform emphasizing automation, ease of use, and integration into existing development workflows.

With StackHawk, developers and security teams can:

Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.

Conclusion

In this blog, we delved into the complexities of Broken Object Level Authorization (BOLA) vulnerabilities. We unpacked the essence of BOLA, revealing how it emerges from insufficient authorization checks, allowing attackers to manipulate or access data beyond their permissions. The discussion illuminated the root causes, from over-reliance on predictable object identifiers to the lack of validation and authorization in API requests. We looked into understanding BOLA's mechanics and the significance of adopting a defense strategy encompassing strong authorization checks, ABAC, and a zero-trust approach, among other security best practices.

From a practical perspective, we looked at how to identify a BOLA vulnerability within a NodeJS application using StackHawk, a cutting-edge Dynamic Application Security Testing (DAST) tool designed for developers. By integrating security testing directly into the development workflow, StackHawk pinpointed the BOLA vulnerability and provided actionable insights to remediate it effectively. Through a simple example, we showcased the power of adding authentication and authorization middleware to secure API endpoints against unauthorized access, thus mitigating the BOLA threat we introduced in the original code.

Embracing StackHawk in your development cycle equips your team with the necessary tools and insights to tackle security vulnerabilities, including BOLA, preemptively. This approach not only enhances the security posture of your applications but also fosters a culture of security mindfulness among developers. Experience firsthand how StackHawk's seamless integration and developer-centric solutions can transform your application security testing workflow, ensuring your applications are robust against common API threats outlined in the OWASP API Security Top 10. Sign up for a free trial of StackHawk today and join the ranks of proactive developers who are “shifting left” and making API security an integral part of their development process with StackHawk.

Bridging the Gap: The Importance of Understanding How Software is Built

Alexa Sevilla

Software plays an integral role in nearly every aspect of our lives. It is the backbone of modern society, from the apps on our smartphones to the systems that power our workplaces. However, for most people, including those responsible for securing software, the process of how software is built remains shrouded in mystery. In this blog post, we'll explore the critical importance of understanding how software is built, emphasizing the need for security teams to empathize with developers and why this bridge-building is vital.

1. The Foundation of Digital Transformation

Understanding how software is built is essential because it forms the foundation of the ongoing digital transformation. As businesses and organizations strive to become more agile and efficient, they rely on software to streamline processes, enhance customer experiences, and gain a competitive edge. Without a basic grasp of the software development process, stakeholders may struggle to make informed decisions about technology investments, project timelines, and resource allocation.

2. Effective Collaboration

Effective collaboration is the lifeblood of successful software development projects. Developers, designers, product managers, and quality assurance professionals must work together seamlessly to create high-quality software. When teams that have been historically outside of this process, such as security, lack an understanding of the development process, miscommunication and misunderstandings can arise. This can lead to delays, cost overruns, and, most importantly, security vulnerabilities going unnoticed.

3. Bridging the Gap: Empathy for Developers

One of the keys to fostering effective collaboration between security teams and developers is empathy. Empathy involves understanding and appreciating the challenges and constraints faced by others. In the context of software development, it means security teams must put themselves in developers' shoes.

Developers constantly balance delivering features quickly and ensuring the software's security. They often work under tight deadlines and are under immense pressure to keep pace with the rapidly evolving technology landscape. Security teams that empathize with these challenges can tailor their security practices and recommendations to be more developer-friendly.

4. Enhanced Security

Security is no longer a "nice to have." Cyberattacks and data breaches are rising, and software vulnerabilities are a common target. When security teams and developers collaborate effectively, security measures become an integral part of the software development process from the start. Developers who understand security concerns can proactively implement best practices, code securely, and identify vulnerabilities early in the development lifecycle. This reduces security risks and lowers the cost of fixing vulnerabilities later in the development process.

5. Building Trust and Resilience

Understanding how software is built and fostering empathy between security teams and developers builds trust within an organization. Developers are more likely to accept and embrace security recommendations when they come from colleagues who understand the development process. This trust enables teams to build resilience against security threats, creating a culture where everyone plays a role in securing the organization’s assets.

6. A Collaborative Future

The importance of understanding how software is built cannot be overstated. It is critical in digital transformation, effective collaboration, and enhanced security. Security teams must bridge the gap by cultivating empathy for developers, recognizing their challenges, and working together to create a secure and efficient development environment. This collaboration not only strengthens an organization's security posture but also lays the groundwork for a more collaborative and successful future in the ever-evolving world of software development.

Alexa Sevilla is Director of Product Marketing at StackHawk

Contact a StackHawk expert to learn how shifting security left can benefit your business
Try StackHawk today - free trial
Watch a demo

Understanding and Protecting Against API1: Broken Object Level Authorization

StackHawk

Imagine a scenario where a simple change in a URL grants an attacker access to your most sensitive data or even control over physical systems. That's the potential danger of broken Object-Level Authorization (BOLA), a widespread vulnerability plaguing APIs. BOLA can expose your financial records, medical information, or any data your application handles to malicious actors.

Broken Object Level Authorization occurs when an API fails to implement strict controls around who can access what. It's like leaving your house unlocked and hoping nobody with bad intentions walks in. In the world of APIs, attackers can manipulate object identifiers (like usernames, order numbers, or document IDs) to gain unauthorized access to resources they shouldn't have.

In this blog, we'll uncover the nature of this vulnerability and explore real-life examples of the damage it can cause. Most importantly, we'll arm you with the knowledge and strategies you need to safeguard your APIs, keeping your data and systems secure.

What is Broken Object Level Authorization (BOLA)?

Broken Object Level Authorization (BOLA), formerly known as Insecure Direct Object Reference (IDOR), consistently ranks as a top API security threat. In essence, it occurs when an API lacks strict checks to ensure a user is only accessing data or resources for which they have legitimate permissions.

Object-level authorization refers to an application's controls determining which users can perform actions on specific data objects. For instance, a healthcare app should ensure that patients can only view their medical records, not those belonging to others. The term "broken" in BOLA means that these authorization controls are either missing or flawed. This might manifest as an API relying too heavily on easily predictable object identifiers (such as customer IDs) or failing to validate if the user making the request has the proper permissions for the action.

BOLA attacks usually follow a pattern. First, the attacker analyzes API requests and responses, looking for patterns in how objects are referenced (e.g., /users/{userID} or /orders/{orderID}). Then, they experiment by changing the value of those object identifiers in their requests, attempting to access data belonging to other users or resources. If the API doesn't enforce proper authorization, the attacker could successfully view, edit, or even delete sensitive data. In the most critical cases, they might gain complete control over objects they should not be able to manipulate.

BOLA is widespread and dangerous due to its ease of exploitation (often requiring minimal technical skill on the attacker's part) and the difficulty in detecting such vulnerabilities with standard security scanners. The impact of a successful BOLA exploit can range from privacy breaches to full-on account compromises, financial fraud, or even the sabotage of systems controlled through the API.

What is the difference between BOLA and Insecure Direct Object Reference (IDOR)?

You may have encountered both "BOLA" and "IDOR" used to describe this type of API vulnerability. While there's significant overlap, there's a subtle but essential distinction. Insecure Direct Object Reference (IDOR) is the older term, while Broken Object Level Authorization (BOLA) is the more current name for this widespread security flaw.

IDOR focuses on APIs that expose internal object references or identifiers an attacker can easily manipulate. Think of a URL structure like /api/customers/{customerID} where an attacker might change the customerID to try accessing other users' data. The shift to the term BOLA emphasizes that the core problem isn't simply the type of reference used but a deeper issue: broken authorization logic. This could manifest in several ways, including the reliance on predictable object identifiers or failure to rigorously validate that the user making the request has ownership or legitimate permissions to interact with the targeted object.

To sum up, all IDOR vulnerabilities are examples of BOLA. However, not all BOLA vulnerabilities necessarily involve directly exposed and easily manipulated object references. The heart of the matter always lies in a failure to implement object-level authorization checks correctly within the API.

What is the root cause of BOLA?

BOLA vulnerabilities stem from flawed development practices prioritizing ease of implementation over robust authorization controls within API logic. Let's dissect the primary factors that lead to this issue:

Over-reliance on Object Identifiers

Directly referencing objects in API endpoints and requests using sequential numerical IDs, predictable strings, or other easily discernible patterns invite exploitation. Consider a URL like /api/documents/{documentID}. An attacker can easily substitute values for {documentid} to access documents they shouldn't have access to. While convenient for developers, using these references as the sole authorization factor is a significant security pitfall.

Lack of Ownership and Permission Verification

A fundamental misstep is failing to consistently validate that the user attempting an action has legitimate ownership of the targeted object or the necessary permissions to perform the action. APIs must verify these rights on a per-request basis.

Blind Trust in User Input

Any data a user provides, including object identifiers, must be treated with suspicion. Thorough input validation and sanitization are essential to prevent attackers from crafting malicious values that could subvert API logic. Failing to do so leaves the system vulnerable to unexpected manipulations that authorization checks might miss.

Insufficient Focus on Authorization

In pressured development environments, an API's core functionality can sometimes overshadow security considerations. This could lead to inconsistent authorization logic, with some endpoints rigorously protected and others left vulnerable. Worse, authorization might be omitted altogether from certain API operations.

The Fallacy of Obscurity

Developers might wrongly believe that using hard-to-guess object identifiers (like long UUIDs) is sufficient protection. However, determined attackers will find ways to discover or predict these references, rendering a false sense of security.

In essence, BOLA boils down to a failure to explicitly and meticulously implement object-level authorization checks within the API. Convenience and assumptions of obscurity should never replace robust authorization mechanisms.

What is an Example of BOLA?

Let's explore more scenarios to illustrate how BOLA can appear in different applications and understand the common pitfalls leading to these vulnerable patterns. Here, we will look at three scenarios covering various ways this vulnerability could manifest.

Scenario #1: Leaky Social Media Profiles

Imagine that a social media platform allows users to update their profile information with an API endpoint like this:

If the API blindly trusts the provided user ID and doesn't verify it against the ID of the currently logged-in user, an attacker could modify anyone's profile. By allowing attackers to access the API without verifying that they only have access to change their specific profile, the social media platform could face reputational damage, spread misinformation, or even facilitate social engineering attacks. To prevent this, the API needs a mechanism to tie the logged-in user's session to their legitimate ID and ensure that submitted objects belong to them.

Scenario #2: Medical Record Tampering

Next, let's look at a healthcare system that has an API to retrieve patient records. For example, the API may look like this:

GET /api/patients/{patientID}/records

Confidentiality is compromised if any authenticated user (regardless of role) can retrieve any patient's records by changing the patient ID. So even though the API checks to see if the user is authenticated, it may not check to see if the user should have access to that patient's docs. The consequence of this could include a breach of sensitive medical information, and if the endpoint allows for data to be changed (such as a POST, PUT, or PATCH), there is also the potential for incorrect or malicious diagnoses and unauthorized record changes. To prevent this, strict role-based access control must be integrated into the API, ensuring users only access and change the data they legitimately need.

Scenario #3: Unintended Invoice Manipulation

Lastly, let's imagine a B2B invoicing system where there is an API to mark invoices as paid:

POST /api/invoices/{invoiceID}/markPaid

Attackers could disrupt cash flows if the API doesn't check the relationship between the logged-in user's company and the invoice ID. If invoice numbers are sequential, this could be made even more accessible. The potential consequences of this include having invoices that have already been paid be changed to unpaid invoices, which could harm business relationships. Falsely marking invoices as paid could lead to financial losses and revenue loss. To prevent this, the API must associate invoices with specific companies/accounts and verify that the user making changes is authorized for those entities.

Based on these examples, it's clear that BOLA is about failing to ask and enforce the question, "Is this user allowed to do this to this specific object?". Security and preventing BOLA attacks shouldn't be an afterthought; authentication and authorization should be baked into every API endpoint's design.

How to Protect Against BOLA

Although we've briefly covered how to prevent BOLA in the examples above, Let's dig further into the specifics. At the highest level, API development must adopt a more integrated approach toward authorization to protect against Broken Object Level Authorization (BOLA) threats. This approach ensures that authorization is not merely an auxiliary feature but a foundational aspect of API security. Below, we explore essential strategies that developers and organizations can adopt to fortify their APIs against BOLA vulnerabilities:

Rethinking Object Identifiers

Firstly, it's crucial not to depend solely on object identifiers like sequential IDs or UUIDs. While these identifiers might seem secure, they can be easily manipulated by attackers skilled in pattern recognition, leading to unauthorized access to sensitive resources. To counter this, implementing a comprehensive session management system is advisable. Such a system, complemented by user roles and permissions, enables fine-grained access control. Additionally, associating object identifiers with authenticated user sessions and their permissions can significantly bolster the legitimacy of access requests.

Strict Authorization Checks

Secondly, enforcing proper access control and strict authorization checks at every API endpoint is non-negotiable. These checks should verify the requestor's identity and confirm their ownership or permission levels regarding the object or action they are trying to initiate. This dual-layer verification is a barrier against unauthorized users and access and should help prevent BOLA.

Importance of Input Validation and Sanitization

Thirdly, the importance of input validation and sanitization cannot be overstated. Malicious users often craft inputs designed to exploit vulnerabilities in API authorization logic. The risk of injection attacks is heavily reduced by ensuring that object identifiers adhere to expected formats and sanitizing inputs to reject or escape special characters.

Principle of Least Privilege

As with any system with sensitive data, the principle of least privilege offers another layer of defense. This principle helps to limit user and system component permissions to the bare minimum necessary for their roles or tasks. This approach minimizes the potential impact of a BOLA breach, as compromised accounts are restricted in their actions.

Leveraging API Gateways

Lastly, the adoption of API gateways can significantly enhance API security. API gateways facilitate the implementation of sophisticated authorization mechanisms by serving as centralized points for policy enforcement and security controls. This strengthens security and promotes consistency across an organization's entire API ecosystem.

Overall, protecting against BOLA requires a comprehensive and proactive approach that integrates robust authorization measures into the very fabric of API development. By adopting these strategies, developers, and organizations can significantly mitigate the risk of BOLA vulnerabilities and safeguard their digital assets. To see how to do some of the above in an end-to-end example, check out our guide on preventing BOLA in Node.

How StackHawk Can Help Detect and Prevent BOLA

When it comes to traditional DAST solutions, BOLA detection was usually not on the menu. Luckily, StackHawk goes beyond traditional DAST solutions by actively testing for BOLA (Broken Object Level Authorization) and IDOR vulnerabilities.

With StackHawk, developers and security teams can:

Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.

Enabling BOLA Detection in HawkScan

Enabling BOLA (and IDOR) detection in StackHawk is easy. Two ways to do this are using the "OpenAPI - Experimental" policy or customizing an existing policy. The "OpenAPI - Experimental" policy allows users to scan for the vulnerabilities outlined in the OWASP API Security Top 10.

To set HawkScan up with the "OpenAPI - Experimental" policy, you will log into StackHawk, go to the Applications screen, and click on the settings link for your application.

Next, on the Settings screen, under HawkScan Settings, click the Applied Policy dropdown and select the "OpenAPI - Experimental" policy.

Next, click the Edit Policy button right beside the dropdown.

On the next screen, under the Plugins and Tests section, click on the BOLA entry to enable HawkScan to execute tests for potential BOLA vulnerabilities.

If you also want to enable IDOR testing, you can click on the Passive Scan Plugins tab and then select IDOR.

Regardless of how you have enabled BOLA testing in HawkScan, your tests will include testing for potential BOLA vulnerabilities (and IDOR, if you enabled it)!

Conclusion

Understanding BOLA is a crucial first step in securing your APIs, but implementing robust authorization mechanisms in the real world can be complex. The key lies in empowering your developers with the tools and knowledge they need to build security into the core of your API design.

StackHawk goes beyond simply identifying potential BOLA vulnerabilities in your running application. It bridges the gap between detection and remediation by providing clear explanations, actionable guidance, and seamless integration into your existing development workflows. This collaborative approach makes API security less intimidating and helps developers instill secure coding practices.

By proactively using StackHawk to detect and address BOLA vulnerabilities, you can significantly minimize the risks of this common API threat. Sign up for a 14-day free trial of StackHawk today to experience the difference StackHawk makes in detecting BOLA vulnerabilities and other API security issues outlined in the OWASP API Top 10.

Understanding and Protecting Against OWASP API10: Unsafe Consumption of APIs

StackHawk

In our increasingly interconnected world, APIs (Application Programming Interfaces) form the backbone of modern digital systems. They power seamless data exchange and enable applications to communicate effortlessly. Because of their rise in usage and popularity, they’ve also become a target for bad actors to exploit. This has led to the OWASP Top 10 API Security Risks, a list developed by OWASP to highlight the top API vulnerabilities that could be and are exploited in the wild. One of the vulnerabilities highlighted in the 2023 edition of the list, in tenth position, is API10: Unsafe Consumption of APIs.

With so many APIs available from third-party providers, our reliance on external APIs can introduce hidden dangers. The OWASP API10: Unsafe Consumption of APIs vulnerability highlights how interactions with untrusted, compromised, or poorly designed third-party APIs can significantly jeopardize your application's security. In this blog, we'll delve into this vulnerability and help you fortify your API endpoints against such an attack.

Understanding OWASP API10: Unsafe Consumption of APIs

At its core, the OWASP API10 vulnerability arises when developers integrate their applications with other APIs without thoroughly assessing those external dependencies' trustworthiness and security posture. Since third-party APIs might adopt weaker security standards, it can make them susceptible to certain vulnerabilities. Scenarios that could lead to the "unsafe consumption of APIs" vulnerability include:

Dependency on Vulnerable APIs: If an external API your application relies on has known vulnerabilities, attackers could exploit those weaknesses to gain unauthorized access to your application's sensitive data or functionality.
Lack of Validation: Not adequately validating data received from third-party APIs could lead to injections (like SQL injections or command injections), allowing attackers to manipulate your application's behavior.
Over-Reliance on APIs: If you expose too much of your own application's critical functionality through APIs, other systems making calls to those APIs could inadvertently open up security risks.

The Impact: What's at Stake?

Unsafe consumption of APIs can have far-reaching consequences, compromising the security and integrity of your application. Here's a look at some potential impacts:

Data Breaches: Attackers could exploit vulnerabilities in integrated APIs to access, manipulate, or steal confidential user data stored in your application.
System Takeover: Attackers might leverage API weaknesses to hijack your application's functionalities or gain complete control over your systems.
Denial of Service (DoS): Malicious actors could flood vulnerable APIs with requests, overwhelming your application and rendering it unavailable to legitimate users.
Reputational Damage: A security breach stemming from this vulnerability can seriously erode trust in your application, leading to loss of customers and revenue.

Unsafe consumption of APIs tends to stack on top of other known vulnerabilities, such as SQL and script injection. If the third-party applications are vulnerable to these types of attacks then, without the proper mechanisms in place, your application also becomes susceptible too.

A Real-World Example of Unsafe API Consumption

Let's illustrate the OWASP API10 vulnerability with a Python (Flask) example. Consider a simple API endpoint that uses a third-party weather API. Below is some code that exposes a /weather/{city} endpoint that retrieves the weather data for a specific city passed to the endpoint. The data passed through the {city} parameter is then used to call the third-party weather API.

If the third-party someweathercompany.com API is compromised or suffers from an injection vulnerability, a malicious user could provide a specially crafted input to the {city} parameter. Since the data sent to the API is not sanitized or checked, this parameter could expose sensitive data from your application or allow the attacker to execute arbitrary code on your backend system.

To understand attacks, let's explore some potential malicious scenarios that target the vulnerable weather API example above.

Scenario #1: Indirect SQL Injection

Imagine our weather app allows users to save their favorite locations and offers localized weather forecasts. To obtain precise coordinates, it relies on a third-party geocoding API. However, the geocoding API has a vulnerability that attackers can exploit to inject malicious code into location names. A clever attacker might submit a location like:

New York'; DELETE FROM saved_locations --

If our application blindly stores this data in its database and later builds dynamic SQL queries using it, the injected payload could delete a user's saved locations or cause even more extensive damage.

Scenario #2: Manipulated Redirects

Let's say our application wants to partner with a third-party API to provide historical weather data for a given location and date. If this weather history API becomes compromised, attackers could manipulate it to send redirects for API calls, like so:

Original Request to Weather History API:

https://weatherhistoryapi.com/data?location=London&date=2023-02-27

Malicious Redirect Response (HTTP 308):

Location: https://attacker.com/collect_data

An application that doesn't carefully handle redirects might blindly resend the request, including sensitive location and date details, to the attacker-controlled server.

Scenario #3: Tricky Filenames

Although possible but less likely, let’s imagine our weather app has a niche feature allowing users to upload their weather observations. These files are stored, and their filenames are kept in a database. An attacker could upload a file named:

weather_data_2023.csv'; DROP TABLE user_data; --

If our app isn't rigorously sanitizing filenames before using them in database interactions, this payload could lead to losing important user data.

Although these are just a few possible scenarios, they highlight how vulnerabilities in external systems we depend on can cascade into problems for our applications. Of course, for these particular exploits, our /weather/{city} can implement some logic to prevent such attacks from being effective. Let’s look at how that can be done in the next section.

Prevention: Best Practices to Secure API Consumption

Vigilance is crucial when working with external APIs. As API interactions happen, developers should ensure that user input is properly handled and that any interaction with any integrated third-party services is limited to only what is required for your app. Making sure that your API that leverages the third-party API is secure requires quite a few important factors. Let’s look at a short list of what to look out for and what to do.

Inventory and Assessment:
- Maintain a comprehensive list of every third-party API you interact with.
- Thoroughly research their security track record. Look for documented vulnerabilities, patch processes, and their overall security posture.
Input Sanitization and Validation (Always!)
- Never trust data from external APIs. Apply rigorous input validation to everything you receive.
- Whitelist Allowed Characters: Create a strict list of permitted characters for inputs like location names. Reject everything else.
- Parameterize Queries: When interacting with databases, use parameterized queries to separate user-supplied data (even data coming through third-party APIs ) from your query logic, eliminating a major vector for injection attacks.
Principle of Least Privilege:
- Expose only the absolute minimum API functionality required. Avoid giving third-party systems wide access to your data or actions.
Secure Communication:
- Always use HTTPS for communication with APIs to protect data in transit.
Error Handling with Care:
- Avoid returning verbose error messages from upstream APIs. Return generic, non-informative messages to limit potential information leaks for attackers to exploit.
Continuous Monitoring
- Monitor external APIs for new vulnerabilities, security advisories, and updates. Regularly review your API usage patterns for anomalies.

Fixing Our Weather API Code

With this in mind, let’s apply some of these tips to our existing weather API. Below is a new and improved version of the API that includes some of the measures we covered above.

As we saw, the original version of the target API, the /weather/{city} endpoint, didn't have any measures to prevent malicious input from being sent to the weather API. This made it susceptible to various attacks like SQL injection or command injection. The code above adds additional logic for input sanitization and error handling. Here are the specifics we’ve added:

Input Sanitization: We've introduced a regular expression (re.match(r"^[A-Za-z0-9 ]+$", city)) to ensure the city parameter from the user consists only of letters, numbers, and spaces. This whitelist approach significantly reduces the surface area for attacks by rejecting unexpected characters.
Error Handling: A simple error message ("Invalid city name") is returned if the input validation fails. This gives the user feedback without revealing sensitive or verbose implementation details that an attacker might misuse.

These changes implement the core security principle of "never trust user input." By sanitizing the data before it's sent to the external weather API, we've added a crucial layer of defense against potential injection attacks. This protects both your server from direct compromise and prevents your application from being used as a tool to attack the weather API itself.

Beyond the Basics

Beyond adding some additional logic to the code directly, we can also add additional measures using other tools. These include adding rate limiting and monitoring mechanisms for the API endpoint.

For rate limiting, you’ll want to implement it on your side as an additional layer of protection, even if the weather API has its own limits in place. This can easily be done by using an API gateway or API management solution.

To monitor your APIs, you can set up logging and monitoring for API interactions (both requests you send and responses you receive) to detect unusual activity or unexpected errors. Various API monitoring and analytics solutions can alert you when specific criteria, such as potentially malicious usage, occur.

StackHawk: Your API Security Ally

Manually identifying and fixing API vulnerabilities can be time-consuming and prone to oversights. StackHawk offers a powerful solution to streamline the improvement of your API security posture against the threats outlined in the OWASP API Top 10. Developers who use StackHawk can leverage:

Automated Scanning: StackHawk probes your running APIs in pre-production and production environments, uncovering vulnerabilities that static code analysis might miss.
OWASP Alignment: StackHawk's testing targets explicitly a wide range of vulnerabilities from the OWASP API Top 10, including issues like BOLA, injection flaws, and inadequate resource consumption protections.
Actionable Guidance: Beyond just identifying problems, StackHawk offers clear remediation instructions and contextual information, empowering developers to resolve vulnerabilities quickly.
Integrates into Your Workflow: StackHawk seamlessly plugs into your existing CI/CD pipelines, enabling continuous security assessment as a part of your development process.

With StackHawk, you can proactively discover vulnerabilities before they hit production, prioritize fixes, and empower developers to “shift left”. Sign up today to try out StackHawk for yourself and begin tackling the OWASP Top 10 API Security Risks with ease and automation!

Finding and Fixing SQL Injection Vulnerabilities in Flask (Python) with StackHawk

StackHawk

In today’s rapidly evolving digital landscape, the security of web applications and APIs is more crucial than ever. With cyber threats becoming increasingly sophisticated, protecting sensitive data against unauthorized access is a top priority for developers and businesses. Among the numerous security vulnerabilities that frequently plague web applications and APIs, SQL Injection stands out as one of the most dangerous and prevalent.

In this blog, we delve into the world of web application security by exploring SQL Injection vulnerabilities. First, we will build a simple API with Flask, then configure StackHawk and use HawkScan through the Hawk CLI to identify any vulnerabilities. This hands-on approach will highlight how SQL injection vulnerabilities are introduced and demonstrate practical steps to fix them. After addressing the SQL injection vulnerability in our code, we'll retest with StackHawk to ensure the security issue is resolved. Let’s start by looking at the basics of StackHawk and SQL injection.

What is StackHawk?

With StackHawk, developers and security teams can:

Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.

What is SQL Injection?

SQL Injection (SQLi) is a type of security vulnerability that occurs in the database layer of an application. It allows attackers to interfere with the queries that an application makes to its database. This can lead to various harmful outcomes, including unauthorized viewing of data, deletion of data, and, in some cases, complete control over the database.

The vulnerability arises when an application uses user input in its SQL queries without proper validation or escaping. Attackers can exploit this by injecting malicious SQL code through the application's input channels (like forms, URLs, API endpoints, etc.), which can unintentionally manipulate the database.

For example, consider an API that uses a URl parameter to retrieve user information from a database. If this input is inserted into a SQL query without proper safeguards, an attacker could input SQL commands that the database will execute. This could lead to unauthorized access to sensitive data, such as passwords, personal information, etc.

SQL Injection can be classified into different types, such as:

In-band SQLi: The most common and straightforward kind, where the attacker uses the same communication channel to launch the attack and gather results.
Inferential SQLi: The attacker sends data payloads to the server and observes the response and behavior of the server to learn about its structure.
Out-of-band SQLi: Used when the attacker can't use the same channel to launch the attack and gather information, often relying on server capabilities to send data to the attacker.

SQL Injection is a high-severity vulnerability because it can compromise sensitive data and take over database systems. Fortunately, with the right tools and practices, it can be detected and remediated effectively, which we will explore in this blog with the help of StackHawk and HawkScan.

How can SQL injection impact application security?

SQL Injection can have a profound and detrimental impact on application security, with consequences ranging from data breaches to complete system compromise. Here’s how SQL Injection can affect application security:

Data Breach: The most immediate threat posed by SQL Injection is unauthorized access to sensitive data. Attackers can exploit vulnerable inputs to extract data from the database, exposing personal information, financial details, and other confidential data.
Data Loss and Corruption: SQL Injection attacks can also be used to delete or modify data in the database. This can result in data loss, data integrity corruption, and application functionality disruption.
Unauthorized System Access: In severe cases, SQL Injection can lead to a complete system takeover. Attackers can use advanced SQL Injection techniques to escalate their privileges within the database, allowing them to execute administrative operations and potentially gain access to the underlying server.
Legal and Compliance Issues: A successful SQL Injection attack can lead to violations of data protection regulations like GDPR, HIPAA, etc. This can result in hefty fines, legal action, and damage to the organization's reputation.
Loss of Trust: Customers and users lose trust in applications and businesses that fail to protect their data. A single SQL Injection vulnerability that leads to a data breach can have long-lasting repercussions on an organization's credibility and customer loyalty.
Financial Costs: Dealing with the aftermath of a SQL Injection attack can be costly. Expenses can include legal fees, regulatory fines, costs associated with rectifying the breach, and investments in upgrading security measures.

Preventing SQL Injection requires a multi-faceted approach, including proper input validation, use of prepared statements, regular security testing, and awareness training for developers. Tools like StackHawk play a crucial role in identifying potential SQL Injection vulnerabilities, enabling teams to address these issues before they lead to security incidents proactively.

Finding and Fixing SQL Injection in a Flask API

Now, we will understand SQL injection a bit more deeply by creating a simple API with an endpoint containing a SQL injection vulnerability. In this step-by-step guide, we will create an API using Flask, then set up StackHawk to test the application through HawkScan and the Hawk CLI. Once the vulnerability is reported, we will fix the injection flaw and retest to ensure it’s indeed fixed.

Creating an API with Flask

In this part of the guide, we will create our base project and its corresponding API. For this, we will rely on Flask. To follow along, you will need to ensure that you:

Have Python and pip installed
Have an IDE where you can edit text
Optionally, have a tool that you can send API requests through to test the endpoint, such as Postman or Insomnia

With the prerequisites above, you can proceed with each step below.

Step 1: Create and Initialize the Project

First, create a new directory for your project and navigate into it. If you do this through a terminal, you can run the command below.

mkdir sql-injection-api-example

cd sql-injection-api-example

Next, with the terminal pointed to the root directory, Initialize a new Python project/virtual environent using the following command.

python3 -m venv venv

source venv/bin/activate

Finally, before we write any code, we will Install the following dependencies:

Flask: for setting up the server.
Flask_SQLAlchemy: for ORM support.
SQLite: for the database (chosen for simplicity; no separate DB server needed).

To do this, using the same terminal pointed to the project root, run the following:

pip install Flask Flask_SQLAlchemy flask-restx

Step 2: Create the Application Code

After creating and opening the app.py file, add the following code:

For those wondering about the code above, this Flask application establishes a simple web API connected to a SQLite database using SQLAlchemy for basic setup but diverges from ORM best practices for query handling. It initializes a Flask server and configures it to connect to a SQLite database, defining a User model for database interactions. However, the application introduces a significant security vulnerability by directly incorporating user input into SQL query strings in the /users/<id> endpoint. This approach makes the application susceptible to SQL injection, as it executes raw SQL queries without sanitizing or parameterizing the user input. Finally, once started, the server will listen for incoming API requests.

For this particular API, we also included the ability to retrieve an OpenAPI Spec. To do this, you will see that we are using the Flask-RESTx dependency to create the OpenAPI Spec and an endpoint, /api-spec, that will return the generated OpenAPI Spec.

Step 3: Running the Application

Finally, let's start the Flask application by executing the following command in a terminal, ensuring you're in the root directory of your project:

flask run -p 4000

Next, let’s quickly check to make sure that our endpoint is working as intended. As you can see In the provided Flask application, the vulnerability lies in the /users endpoint. The endpoint concatenates user input directly into an SQL query without sanitization or parameterization. This makes it susceptible to SQL injection.

In Postman, you can send a simple request to the endpoint. For instance, suppose you want to query the user with ID 1. For this, you could use the following GET request:

http://localhost:4000/users/1

In a malicious query, an attacker could exploit the SQL injection vulnerability by providing an SQL snippet in the id parameter. For example, they could use the following amended GET request:

http://localhost:4000/users/1 OR 1=1

This query would cause the SQL command to return all rows in the users' table because ‘1=1’ is always true. What happens in this scenario is that the SQL query executed by the server turns into something like this:

SELECT * FROM users WHERE id = 1 OR 1=1

Since 1=1 is always true, this condition bypasses the intended filter and can potentially expose all the data in the users' table. In the case above, you’ll get the returned data from all three default users we added in the code instead of just a single user.

Configure StackHawk

Now that our code is set up and our API is running, let’s get StackHawk to identify this vulnerability for us automatically. To do this, you’ll need to make sure that you have a StackHawk account. If you need one, you can sign up for a trial account or log into an existing account.

If you’re logging into an existing StackHawk account, from the applications page you’ll click Add an App -> Create Custom App

Lastly, we will need to add a stackhawk.yml file to the root of our project. Once the file is added, copy the screen's contents, paste it into the file, and save it. Once complete, we can run the “hawk scan” command in a terminal pointing to the root of our project. Lastly, we can click the Finish button.

Run HawkScan

After running the “hawk scan” command in the previous step, you should see the tests beginning to execute in the terminal.

This will run tests against our API based on the OpenAPI spec using the OpenAPI Spider provided by StackHawk.

Explore the initial findings

Once the tests are complete, the terminal will contain some information about any vulnerabilities found. Below, we can see that it has identified the SQL injection vulnerability that we introduced in the code. To explore this further, we will click on the test link that is provided at the bottom of the output. This will take us into the StackHawk platform to explore further.

After clicking on the link, we can now see the test results nicely formatted. Next, we will click on the SQL Injection entry.

Within this entry, we can see an Overview and Resources that can help us with fixing this vulnerability as well as the Request and Response that the API returned. Just above this, you will also see a Validate button, which will display a cURL command with the exact API request used to expose the vulnerability.

Fixing the SQL Injection vulnerability

Now that we have identified the vulnerability, it’s time to fix it. In this case, to prevent SQL injection in the Flask application, the easiest way to fix this is to modify the code to use parameterized queries. This approach ensures that user input is treated as data, not as part of the SQL command. Doing so prevents attackers from injecting malicious SQL code through user input.

Here's how you can modify the vulnerable endpoint in your app.py file to use parameterized queries:

Let's summarize the modifications made to the Flask application to address the SQL injection vulnerability. Initially, the application directly included the `id` parameter from the user input into the SQL query string, creating a significant security risk. To mitigate this vulnerability, the code now employs parameterized queries. In the updated query `text("SELECT * FROM user WHERE id = :id")`, the `:id` serves as a placeholder for the `id` parameter. This placeholder is securely substituted with the actual `id` value provided in the request through the execution method `db.session.execute(query, {'id': id})`. This method of handling user input ensures it is always regarded as a data value rather than executable code, effectively preventing SQL injection attacks.

By implementing these changes, the endpoint is safeguarded against SQL injection threats. The application now consistently treats user inputs as parameters rather than parts of the executable SQL command. This practice is essential in the development of secure applications. It underscores the importance of always validating and sanitizing user inputs, in addition to utilizing parameterized queries for processing SQL statements, to protect against possible injection attacks.

To finalize the adjustments, save the updated code and restart the application. This action ensures that the changes take effect, reinforcing the application's defense against SQL injection vulnerabilities.

Confirm the fix!

With the fix in place, let’s confirm it is working as intended. To do this, back in StackHawk, we will click the Rescan Findings button.

Then, we will see a modal containing the “hawk rescan” command that includes the correct Scan ID. You’ll run this command in the same terminal where you ran the initial set of tests.

In the output, you will again see any vulnerabilities found in the scan. In this case, you’ll see that the SQL injection vulnerability is no longer showing. Clicking on the link at the bottom of the terminal output, you can confirm that the SQL injection vulnerability has now been added to the Fixed Findings from Previous Scan, confirming that the vulnerability has been successfully fixed and has passed any vulnerability tests.

Try it out!

With that, we've successfully used StackHawk to scan an API, identify a SQL injection issue, and confirm that our fix worked as intended. Are you looking to make your applications more secure and put the power of security testing into the hands of developers? With StackHawk, “shift-left” the responsibility of security and empower developers to build secure APIs and applications with ease. Want to give it a try for yourself? Sign up for StackHawk today for a free 14-day trial.

Accelerating Security with StackHawk: Reducing Distance, Maximizing Speed

Scott Gerlach

Hey there, StackHawk fam! Scott here, and today we're diving into why we do things a bit differently when it comes to security testing. You've probably wondered why we don't do scheduled scans from our SaaS platform or offer a hosted scanner. Well, let's break it down, StackHawk style.

1. Reducing Distance: Closer to Your Code

When it comes to dynamic security testing, physical distance matters. Traditional hosted scanners can introduce unnecessary delays due to the distance between the testing engine and your application. Here at StackHawk, we're bringing the testing engine as close to your running application or API as possible. By minimizing distance, we ensure that security scans are lightning-fast and provide real-time feedback to keep your development process moving at warp speed.

2. Maximizing Speed: On-Demand, Instant Results

Nobody has time to wait around for scans queued up in a vendor's scheduler anymore. With StackHawk, you can fire off tests on-demand, or use your own CI/CD scheduling infrastructure (you know your CI/CD can schedule activities, right?) to get instant results any time a developer commits code or deploys apps into QA. You can scan all the things in parallel as needed, no waiting, no delays—just rapid feedback to help you squash those vulnerabilities and ship code with confidence. Speed is our middle name (well, not literally, but you get the idea).

Take it from our friends at One Medical, “The process of scanning the application and integrating with CircleCI was super easy...With StackHawk's CircleCI Orb, teams can quickly add an application security test to the build pipeline, ensuring visibility to any newly added vulnerabilities before the application is in production.”

3. Protecting Credentials: Eliminating Exposure

Now, let's talk about security, because, well, that's kind of our thing. The hardest part of dynamic testing is often authentication. One big advantage of not having a hosted scanner? We keep your authentication credentials right where they belong—in your hands. I definitely don’t want them. With traditional scanners, you're often handing over sensitive credentials to a third party, opening up all sorts of potential risks. By nixing the hosted scanner, we minimize exposure and keep your credentials safe and sound.

4. Tailored Solutions: Customized to Your Needs

Every app is unique, and your security testing should be too. StackHawk gives you the power to customize testing to fit your needs. Whether you're fine-tuning parameters, targeting specific endpoints, or prioritizing critical vulnerabilities, we've got you covered. No cookie-cutter solutions here—just tailor-made security testing to keep your code locked down tight. And by the way, if nightly scanning is what you really need, you can do that too in CI/CD.

4. Seamless Integration: Built for DevOps Velocity

We're all about making security a seamless part of your DevOps workflow. With our API-first architecture and CI/CD pipeline integration, you can automate security testing and catch vulnerabilities early in the game. It's all about minimizing risk, accelerating time to market, and keeping your development process humming along smoothly.

Maya’s experience is a hawksome example of this, “With StackHawk, being embedded in the pipeline it enabled our developers to detect and remediate the vulnerability right away even before any security audits, which reduces the time to remediate to only a few days compared to weeks before the implementation.”

5. Speeding Toward a Secure Future

At StackHawk, we're on a mission to make security testing fast, integrated, and developer-friendly. By reducing distance, maximizing speed, and providing tailored solutions, customers have been able to create secure software without sacrificing velocity. Join us in accelerating toward a future where security is not just a checkbox but a fundamental part of every development cycle.

Ready to experience the speed of StackHawk? Book a demo with our team, or sign up for a free trial today!

Finding and Fixing SQL Injection Vulnerabilities in Node (Express) with StackHawk

StackHawk

In today's rapidly evolving digital landscape, the security of web applications and APIs is more crucial than ever. With cyber threats becoming increasingly sophisticated, protecting sensitive data against unauthorized access is a top priority for developers and businesses. Among the numerous security vulnerabilities that frequently plague web applications and APIs, SQL Injection stands out as one of the most dangerous and prevalent.

In this blog, we delve into the world of web application security by exploring SQL Injection vulnerabilities. First, we will build a simple API with Node and Express, then configure StackHawk and use HawkScan through the Hawk CLI to identify any vulnerabilities. This hands-on approach will highlight how SQL injection vulnerabilities are introduced and demonstrate practical steps to fix them. After addressing the SQL injection vulnerability in our code, we'll retest with StackHawk to ensure the security issue is resolved. Let’s start by looking at the basics of StackHawk and SQL injection.

What is StackHawk?

With StackHawk, developers and security teams can:

Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.

What is SQL Injection?

SQL Injection can be classified into different types, such as:

In-band SQLi: The most common and straightforward kind, where the attacker uses the same communication channel to launch the attack and gather results.
Inferential SQLi: The attacker sends data payloads to the server and observes the response and behavior of the server to learn about its structure.
Out-of-band SQLi: Used when the attacker can't use the same channel to launch the attack and gather information, often relying on server capabilities to send data to the attacker.

How can SQL injection impact application security?

Data Breach: The most immediate threat posed by SQL Injection is unauthorized access to sensitive data. Attackers can exploit vulnerable inputs to extract data from the database, exposing personal information, financial details, and other confidential data.
Data Loss and Corruption: SQL Injection attacks can also be used to delete or modify data in the database. This can result in data loss, data integrity corruption, and application functionality disruption.
Unauthorized System Access: In severe cases, SQL Injection can lead to a complete system takeover. Attackers can use advanced SQL Injection techniques to escalate their privileges within the database, allowing them to execute administrative operations and potentially gain access to the underlying server.
Legal and Compliance Issues: A successful SQL Injection attack can lead to violations of data protection regulations like GDPR, HIPAA, etc. This can result in hefty fines, legal action, and damage to the organization's reputation.
Loss of Trust: Customers and users lose trust in applications and businesses that fail to protect their data. A single SQL Injection vulnerability that leads to a data breach can have long-lasting repercussions on an organization's credibility and customer loyalty.
Financial Costs: Dealing with the aftermath of a SQL Injection attack can be costly. Expenses can include legal fees, regulatory fines, costs associated with rectifying the breach, and investments in upgrading security measures.

Finding and Fixing SQL Injection in an Express API

Now, we will understand SQL injection a bit more deeply by creating a simple API with an endpoint containing a SQL injection vulnerability. In this step-by-step guide, we will create an API using Node and Express, then set up StackHawk to test the application through HawkScan and the Hawk CLI. Once the vulnerability is reported, we will fix the injection flaw and retest to ensure it’s indeed fixed.

Creating an API with NodeJS and Express

In this part of the guide, we will create our base project and its corresponding API. For this, we will rely on node and express. To follow along, you will need to ensure that you:

Have node and npm installed
Have an IDE where you can edit text
Optionally, have a tool that you can send API requests through to test the endpoint, such as Postman or Insomnia

With the prerequisites above, you can proceed with each step below.

Step 1: Create and Initialize the Project

First, create a new directory for your project and navigate into it. If you do this through a terminal, you can run the command below.

mkdir sql-injection-api-example

cd sql-injection-api-example

Next, with the terminal pointed to the root directory, Initialize a new Node.js project with npm using the following command.

npm init -y

Finally, before we write any code, we will Install the following dependencies:

Express: for setting up the server.
Body-parser: for parsing incoming request bodies.
SQLite3: for the database (chosen for simplicity; no separate DB server needed).

To do this, using the same terminal pointed to the project root, run the following:

npm install express body-parser sqlite3 express-oas-generator

Step 2: Create the Application Code

Now, we will begin to create our API application. In the root directory of the project, create a file named app.js. This file will contain your Express server and the API endpoint that contains the SQL injection vulnerability.

After creating and opening the app.js file, add the following code:

For those wondering about the code above, this Node.js application, built using the Express framework, establishes a simple web API hooked up to a SQLite database. It initializes an Express server and configures it to parse JSON request bodies. The SQLite database, stored in memory, is set up with a `users` table and pre-populated with example data. The application features an API endpoint (`/users`) that contains a SQL injection vulnerability. Finally, once started, the server will listen for incoming API requests on port 4000.

Step 3: OpenAPI Specification

For this particular API, we will also include an OpenAPI Spec. To do this, we will add an endpoint, /api-spec, that will automatically generate and respond with an OpenAPI Spec. To do this, we will first add the express-oas-generator import to our code (it was already installed earlier in the npm install we ran).

const expressOasGenerator = require('express-oas-generator');

Then, we will initialize the spec generator just under where we define the express app.

expressOasGenerator.init(app, {});

With that, the code at the top of our app.js file will now look like this:

Now, make sure to Save all of the files you’ve updated so that we can run our API service in the next step.

Step 4: Running the Application

Finally, let’s start the Node.js application by running the following command in a terminal (pointed at the root directory of the project):

node app.js

Next, let’s quickly check to make sure that our endpoint is working as intended. As you can see In the provided Node.js Express application, the vulnerability lies in the /users endpoint. The endpoint concatenates user input directly into an SQL query without sanitization or parameterization. This makes it susceptible to SQL injection.

In Postman, you can send a simple request to the endpoint. For instance, suppose you want to query the user with ID 1. For this, you could use the following GET request:

http://localhost:4000/users/1

In a malicious query, an attacker could exploit the SQL injection vulnerability by providing an SQL snippet in the id parameter. For example, they could use the following amended GET request:

http://localhost:4000/users/1 OR 1=1

SELECT * FROM users WHERE id = 1 OR 1=1

Since 1=1 is always true, this condition bypasses the intended filter and can potentially expose all the data in the users' table. In the case above, you’ll get the returned data from all 3 default users we added in the code instead of just a single user.

Configure StackHawk

If you’re logging into an existing StackHawk account, from the applications page you’ll click Add an App -> Create Custom App

Run HawkScan

After running the “hawk scan” command in the previous step, you should see the tests beginning to execute in the terminal.

This will run tests against our API based on the OpenAPI spec using the OpenAPI Spider provided by StackHawk.

Explore the initial findings

After clicking on the link, we can now see the test results nicely formatted. Next, we will click on the SQL Injection entry.

Within this entry, we can see an Overview and Resources that can help us with fixing this vulnerability as well as the Request and Response that the API returned. Just above this, you will also see a Validate button, which will display a cURL command with the exact API request used to expose the vulnerability.

Fixing the SQL Injection vulnerability

Now that we have identified the vulnerability, it’s time to fix it. In this case, to prevent SQL injection in the Node.js Express application, the easiest way to fix this is to modify the code to use parameterized queries. This approach ensures that user input is treated as data, not as part of the SQL command. Doing so prevents attackers from injecting malicious SQL code through user input.

Here's how you can modify the vulnerable endpoint in your app.js file to use parameterized queries:

Let’s recap the changes made in the code to alleviate this vulnerability. First, instead of concatenating the userId directly into the SQL statement, the query is parameterized. The ? in the query "SELECT * FROM users WHERE id = ?" is a placeholder for the `userId`. This placeholder is then safely replaced by the userId value provided in the request. Then, we also use the `db.all` method with an array ([userId]) that safely inserts the `userId` into the query. This ensures that user input is always treated as a value and not executable code, thus preventing SQL injection.

The endpoint is now secured against SQL injection attacks by making these changes. The application treats user inputs as parameters, not as parts of the SQL statement, which is a critical practice in developing secure applications. It’s important always to validate and sanitize user inputs and use parameterized queries to handle data in SQL statements to mitigate potential injection attempts.

Lastly, save the code and restart the application to apply the changes.

Confirm the fix!

With the fix in place, let’s confirm it is working as intended. To do this, back in StackHawk, we will click the Rescan Findings button.

Then, we will see a modal containing the “hawk rescan” command that includes the correct Scan ID. You’ll run this command in the same terminal where you ran the initial set of tests.

Try it out!

Best Practices for gRPC Security

Nicole Jones

gRPC (gRPC Remote Procedure Calls) APIs have become a crucial component in modern application development, revolutionizing how we, as developers, implement inter-service communication. In an era where microservices and distributed systems are prevalent, gRPC APIs, known for their high performance and efficiency, play a pivotal role. They facilitate the robust and rapid data exchange between services, from intricate transactions in global financial systems to real-time data processing in various applications. Beyond their core functionality, gRPC APIs protect sensitive information and systems from cyber threats. With the growing adoption and complexity of gRPC APIs, the need for meticulous security measures is increasingly paramount.

This guide aims to provide a comprehensive overview of API security, specifically focusing on the unique aspects of gRPC API security. We will explore the myriad facets of securing APIs, equipping you with the knowledge to safeguard your gRPC APIs against many potential security threats. From foundational security concepts to advanced protective strategies, this guide ensures the integrity and confidentiality of digital interactions facilitated by gRPC APIs. As we delve into API security, let’s begin with the fundamental question: What exactly is API security?

What is API Security?

gRPC API security is the defensive framework that protects gRPC APIs from cyber threats in today's interconnected digital landscape. This form of security encompasses various aspects, including specialized protocols, systems, and tools, all designed to counteract malicious activities targeting or exploiting gRPC APIs, thus safeguarding crucial elements of modern software communication.

At its core, gRPC API security ensures that only authorized users can perform authorized actions, primarily achieved through robust authentication and authorization processes. These processes are essential for confirming user identities and managing access permissions effectively. Encryption also plays a vital role in gRPC API security, serving as a fundamental tool to protect data as it is transferred between clients and servers. However, the scope of gRPC API security goes beyond mere access control; it includes the monitoring and logging of API activities for threat detection, implementing rate limiting to prevent misuse, and managing the lifecycle of the gRPC API to mitigate exploitable vulnerabilities.

Unlike traditional software development processes, gRPC API security is not a static setup but a dynamic, ongoing process. It must continually evolve to keep pace with the changing threat landscape and adapt to the specific features and integration patterns of gRPC APIs. The overarching goal is to create a secure environment for data exchange that ensures data integrity, availability, and confidentiality while minimizing the surfaces vulnerable to attacks.

Why is API Security Important?

The critical role of gRPC APIs in modern software and applications carries significant risks, especially considering their exposure to the open internet. This exposure makes gRPC APIs inherently vulnerable to cyberattacks. The importance of gRPC API security is deeply rooted in the need to protect sensitive data transferred between services, maintain user privacy, and prevent disruptions in business operations due to malicious activities.

Recently, the consequences of API security breaches have become increasingly evident. Incidents of security breaches can lead to severe outcomes such as data theft, service outages, and substantial financial losses. For instance, an unprotected gRPC API could be exploited by attackers, leading to unauthorized access to sensitive customer data, identity theft, and fraud. While data breaches are often thought of in the context of compromised databases, the potential for such attacks through gRPC APIs, given their efficiency and performance capabilities, is also significant.

Security in the context of gRPC APIs is a vital aspect of users' trust in digital services. A breach in gRPC API security can significantly harm a company's reputation, resulting in a loss of customer trust and loyalty. Furthermore, due to the interconnected nature of modern digital services, a vulnerability in one gRPC API can have a domino effect, impacting connected services and amplifying the severity of a breach.

Thus, securing gRPC APIs is not just a technical challenge but a crucial business imperative. A robust and comprehensive security framework for gRPC APIs is essential to ensure secure and reliable services to users and to adhere to regulatory compliance standards like GDPR and HIPAA.

How Do You Secure a gRPC Endpoint?

gRPC, a high-performance RPC (remote procedure call) framework created by Google, relies on HTTP/2 for transport and a protocol buffer as its interface description language. To secure gRPC APIs, you must address the protocol and the message formats. Setting up and configuring the gRPC client involves importing proto definitions, connecting to the server's IP address, attaching SSL certificates for authorization and encryption, and implementing authentication mechanisms such as SSL, ALTS, OAuth 2.0, and JWT Bearer Token.

Firstly, similar to what was mentioned with the other types of APIs we covered, gRPC services should employ TLS for transport security. Doing this helps to ensure that all data transmitted via gRPC is encrypted and secure from interception. For message-level security, you should utilize the built-in authentication mechanisms provided by gRPC, such as token-based authentication, which can integrate with identity providers such as Auth0 and Okta. Security for the gRPC server is also crucial, including using authentication methods like OAuth 2.0, JWT Bearer Token, OpenID Connect, WS-Federation, and ALTS (if deploying the service on Google Cloud).

Additionally, you’ll also want to make sure always to validate and sanitize all incoming data to prevent injection attacks. With gRPC’s strict schema definitions, you can enforce message validation based on the defined Protocol Buffers. This can help detect abnormal messages that could be part of a potential attack, allowing you to add a mechanism to stop such malicious activity from becoming catastrophic to the system or data. ALTS (Application Layer Transport Security) is used within Google's infrastructure to secure RPC communications, providing mutual authentication and transport encryption.

Lastly, you’ll want to implement fine-grained access control for the service. This is particularly important with gRPC due to its ability to create complex service-to-service interaction patterns. If such interactions go unchecked, attacks may be able to penetrate deep into the systems that are exposed through the gRPC calls. By implementing a robust access control strategy, you can ensure that services only have the permissions necessary to perform their intended functions.

Securing gRPC APIs also involves monitoring and logging all operations to detect and respond to suspicious activities promptly. Robust monitoring and logging also create an audit log, which can be used to see the impact of attacks if they do make it through your defenses. The principles above tie into the more advanced security measures and best practices we will cover later in this guide.

gRPC Security Best Practices

Having established the basics of gRPC API security, it's time to delve into the best practices. This section will comprehensively cover various tools and strategies to ensure your gRPC APIs are as secure as possible.

Conduct Regular Security Audits and Penetration Testing

Security audits and penetration testing are essential for assessing the security of your gRPC APIs. These practices help uncover and address vulnerabilities early in the development process. Regular security audits should thoroughly review your gRPC API's infrastructure, policies, and codebase for compliance with security standards. Penetration testing is a type of API security testing that involves simulating cyberattacks to test the resilience of your gRPC API against real-world threats.

Implement Strong Authentication and Authorization Checks

Robust authentication and authorization are critical for regulating access to your gRPC API. Authentication confirms user identity, while authorization determines their access level. Adopt secure authentication protocols like OAuth 2.0 and OpenID Connect. For authorization, use role-based access control (RBAC) or attribute-based access control (ABAC) to define clear access policies. Implementing multi-factor authentication (MFA) can significantly enhance security.

Encrypt Data in Transit and at Rest

Encryption is vital for protecting sensitive information in your gRPC API. Ensure data is encrypted in transit using TLS with strong cipher suites. For data at rest, use encryption algorithms like AES and manage encryption keys securely with services provided by cloud providers or hardware security modules (HSMs).

Effective Error Handling and Logging

Proper error handling prevents sensitive data leaks from your gRPC API, while logging creates an audit trail for analysis. Develop strategies for uniform error responses and use tools like ELK Stack or Splunk to aggregate and analyze logs. Ensure logs do not contain sensitive information.

Add in Authorization and Authentication Mechanisms

Unless you intend for an API to be used freely, by anyone, adding authorization and authentication can ensure that only users that are supposed to access the service are able to. This could be done through the use of an API token, JWT, or other mechanism.

Use Throttling and Rate Limiting

Implement throttling and rate limiting to control the volume of requests to your gRPC API. These measures prevent service overuse and protect against denial-of-service attacks. API gateways or middleware can manage these controls effectively.

Ensure Proper API Versioning and Deprecation Strategies

Maintain explicit versioning and deprecation strategies for your gRPC service. Use Semantic Versioning (SemVer) and communicate changes through changelogs. When deprecating older versions, guide users to migrate to newer versions.

Embrace a Zero-Trust Network Model

Adopt a zero-trust model for your gRPC API, which involves not automatically trusting any user or system. Enforce strict verification, apply the principle of least privilege, and use micro-segmentation to limit access within your network.

Automate Scanning and Testing for Vulnerabilities

Integrate automated vulnerability scanning and testing into your CI/CD pipeline for your gRPC API. Use tools that support dynamic and static application security testing (DAST and SAST) to analyze code and stay updated with new security threats.

Secure the Underlying Infrastructure

Ensure the infrastructure hosting your gRPC API is secure. Regularly update and patch servers, enforce firewall rules, and use intrusion detection systems. In cloud environments, leverage native security features and adhere to best practices in access and account management.

You can create a robust security framework for your gRPC APIs by implementing these best practices. Remember to tailor these strategies based on the specific types of gRPC APIs you manage, regulatory requirements, and other unique aspects of your security framework.

Augmenting API Security With StackHawk

As mentioned in our breakdown of best practices, StackHawk is a pivotal tool in reinforcing some of the API security concepts outlined above. By bringing a suite of automated testing capabilities that align closely with best practices for API security, StackHawk is a dynamic application security testing (DAST) tool built for developers. The platform is easy to use, automated, and provides a best-in-class experience for developers to create secure APIs. Let’s look further at some of the benefits StackHawk brings to API developers and their teams.

Automated Security Risk Tests and Dynamic Application Security Testing

StackHawk provides an automated suite to test against common and more advanced API security risks. The platform helps to identify and resolve issues like SQL Injection and Remote OS Command Injection before deployment. This capability supports the abovementioned best practices involving regular security audits and penetration testing.

Integration with CI/CD Pipelines

The platform also integrates easily with CI/CD pipelines and can be set up to ensure every pull request is checked for new vulnerabilities. This ties in nicely with the best practice of testing in development to prevent shipping vulnerabilities to production.

Modern Tooling for Various API Types

Unlike some other tools, StackHawk can support various API types when it comes to testing. The tool caters to modern application architectures by supporting REST, GraphQL, SOAP, and gRPC APIs. This helps to ensure that your entire API portfolio has blanket coverage instead of excluding API types that other tools may not support.

Efficient Vulnerability Management

The most powerful outcome for developers that use StackHawk is fast detection and detailed documentation for remediation. StackHawk streamlines the process of fixing vulnerabilities and makes developers' lives easy and the APIs they create more secure. By making the tool developer-friendly, vulnerability management becomes easy to implement and easy for developers to utilize.

By incorporating StackHawk into your API development lifecycle, you can make significant progress towards maintaining a high-security standard and adherence to the best practices outlined in this guide.

Conclusion

As we conclude our in-depth exploration of API security, it's clear that protecting our APIs is critical and complex. Throughout this guide, we've navigated the intricacies of API security, from the foundational principles drawn from the OWASP Top 10 to the nuanced specifics of securing REST, GraphQL, and gRPC APIs. We capped things off with a look at the strategic best practices that can help fortify your digital defenses and reflected on the importance of each in the broader context of API security.

In this continuous quest for security excellence, tools like StackHawk are indispensable. StackHawk empowers teams to augment their API security strategies effectively. With its automated security testing tailored for modern APIs, integration into CI/CD pipelines for early vulnerability detection, and support for a vast array of API architectures, StackHawk ensures that your security testing evolves with your APIs.

As you look to translate the insights from this guide into actionable security enhancements, consider taking StackHawk for a spin. Begin your journey with StackHawk by signing up for a free account and taking the first step in making your APIs as secure as possible.

OWASP Top 10: Finding GraphQL Vulnerabilities with StackHawk

Nicole Jones

As developers, we are well aware that APIs have become an essential part of modern web and mobile applications. Without them, many applications would be unable to facilitate the driving the seamless connectivity between different software components and services that users have come to expect. As APIs continue to grow in both importance and complexity, securing them against potential threats has become a critical challenge for developers and security professionals alike. When it comes to resources for establishing what vulnerabilities to focus on, The Open Web Application Security Project (OWASP) API Security Top 10 list is a vital source of information that highlights the most pressing security risks facing APIs today.

Among the various API technologies that developers currently use, GraphQL has emerged as a game changer, redefining how developers query and manipulate data. Developed by Facebook and released to the public in 2015, GraphQL offers a more efficient, powerful, and flexible alternative to the traditional REST API. From small startups to tech giants, many have embraced GraphQL for its dynamic approach to data retrieval and manipulation. With this growth in adoption and usage, understanding the security implications of GraphQL APIs is more crucial than ever. Developers working with GraphQL implementations need to be aware of GraphQL attacks, which highlight the security vulnerabilities that arise from the use of GraphQL as an API query language.

In this blog, we will bridge the gap between the general security principles outlined in the OWASP API Security Top 10 and the specific needs of GraphQL APIs. We’ll explore each of the vulnerabilities in the top ten, unraveling how they apply to GraphQL. For each risk, we will do a quick analysis, including real-world scenarios, practical examples, and how to mitigate such vulnerabilities. By the end of this blog, you’ll have a comprehensive understanding of not only what makes GraphQL unique but also how to approach the security challenges that GraphQL adoption brings. First stop, let’s take a look at the OWASP API Security Top Ten in more detail before going into how they apply to GraphQL APIs.

Introduction to GraphQL Security

As the popularity of GraphQL continues to grow, so does the need for robust security measures to protect GraphQL APIs from various threats. GraphQL security is a critical aspect of ensuring the integrity and confidentiality of data exchanged between clients and servers. In this section, we will delve into the world of GraphQL security, exploring its key concepts, vulnerabilities, and best practices for securing GraphQL APIs.

GraphQL APIs, like any other API, are susceptible to a range of security threats, including injection attacks, denial of service (DoS) attacks, and unauthorized access. Given the dynamic nature of GraphQL, where clients can request exactly the data they need, it becomes imperative to implement stringent security measures. This includes validating user input, implementing proper access controls, and monitoring for malicious queries.

What is GraphQL?

GraphQL is a query language for APIs that allows clients to request specific data from a server. It was developed by Facebook in 2012 and has since become a popular alternative to traditional REST APIs. GraphQL’s flexibility and ability to provide a great developer experience have made it a preferred choice for many developers.

Unlike REST, where the server defines the structure of the responses, GraphQL enables clients to specify the exact structure of the data they need. This reduces the amount of data transferred over the network and improves the efficiency of data retrieval. Additionally, GraphQL’s strong typing system and introspection capabilities make it easier to understand and document the API.

What is the OWASP API Security Top Ten?

The Open Web Application Security Project (OWASP) is an international non-profit organization dedicated to improving the security of software. Within its many projects, the OWASP API Security Top Ten is the leading resource API developers can use to understand and mitigate the most significant security threats facing web APIs, including GraphQL. Released for the first time in 2019, this list is derived from industry survey data, expert opinions, and reported incidents. The goal of OWASP is to update it periodically to reflect the evolving landscape of API security. The latest update was in 2023.

The OWASP API Security Top 10 list categorizes and prioritizes the top security risks based on their prevalence, potential impact, and exploitability. The 2023 edition includes the following vulnerabilities:

1. Broken Object Level Authorization (BOLA)

2. Broken Authentication

3. Excessive Data Exposure

4. Lack of Resources & Rate Limiting

5. Broken Function Level Authorization

6. Mass Assignment

7. Security Misconfiguration

8. Injection

9. Improper Assets Management

10. Insufficient Logging & Monitoring

Each item on the list encapsulates a broad category of vulnerabilities, offering insights into their causes, manifestations, and potential impacts. This framework guides developers, security analysts, and IT professionals in creating, deploying, and maintaining secure APIs. To view the entire resource, you can check out the OWASP site.

Are the OWASP API Security Top Ten Applicable to GraphQL Endpoints?

At its core, the OWASP API Security Top 10 addresses concerns that are universally applicable to all types of APIs, including REST and GraphQL. These risks encompass broad security areas like authentication, authorization, data exposure, etc. However, because of how GraphQL APIs work, using GraphQL introduces unique challenges and subtleties in applying these security principles compared to RESTful APIs.

REST vs. GraphQL

When it comes to the debate of what technology to use, most will find that their organization will use a mix of both technologies. The idea of RESTful APIs being entirely deprecated as a technology is a bit of a stretch. REST (Representational State Transfer) APIs have been the standard for web services for many years, characterized by their stateless nature and standard HTTP methods (GET, POST, PUT, DELETE). They are so extensively used that the majority of APIs being used are RESTful. In contrast, GraphQL, seen as a query language for APIs, offers a more dynamic and flexible approach to the function of an API. GraphQL, unlike REST APIs, allows clients to request exactly the data they need in a single query.

There are a few areas of consideration when comparing the two technologies. Here are a few areas where the two technologies differ:

Authorization: In REST, authorization checks are often tied to specific URL endpoints. GraphQL, however, handles a wide range of data through a single endpoint, necessitating more granular, field-level authorization checks.
Data Exposure: REST APIs may expose different endpoints for different data needs, while GraphQL’s single endpoint approach can lead to excessive data exposure if not carefully managed.
Rate Limiting: REST APIs typically rate limit based on the number of requests, but for GraphQL, the complexity of queries also needs to be considered, as a single query can be resource-intensive.

With these points in mind, developers should be able to tell that applying the OWASP Top 10 to GraphQL requires a deeper understanding of the nuances of GraphQL. For example, below are a few points within the OWASP API Top Ten and how the nuances of GraphQL apply to them.

BOLA & Function Level Authorization:

GraphQL’s flexible querying can inadvertently bypass traditional object and function-level authorization controls. This means that GraphQL APIs must have robust and context-aware security implementations.

Authentication & Data Exposure:

GraphQL’s use of a single endpoint for data retrieval can complicate authentication schemes and increase the risk of data exposure. GraphQL schemas handling sensitive data require comprehensive and adaptive security measures.

Complexity & Rate Limiting:

The ability of GraphQL to handle complex queries in a single request means that traditional rate limiting based on request count is insufficient. Instead, more sophisticated approaches like analyzing query complexity and query depth limiting are required.

Injection & Misconfiguration:

While GraphQL is less prone to traditional injection attacks, its resolvers can still be vulnerable. Similarly, misconfigurations in a GraphQL context can have far-reaching implications due to its singular endpoint and complex schema.

In conclusion, while the OWASP API Security Top 10 is universally applicable to all APIs, including GraphQL, the application of these principles requires a tailored approach. This tailored approach should account for GraphQL’s unique capabilities and challenges. Ensuring robust and adequate security in the face of evolving cyber threats is extremely important for all APIs, underscoring the importance of the Top Ten list.

GraphQL Schema and Introspection

A GraphQL schema is the backbone of a GraphQL API, defining the types of data available and the relationships between them. Introspection is a feature of GraphQL that allows clients to query the schema for information about the available types, fields, and relationships.

Understanding GraphQL Schema

A GraphQL schema is composed of several key elements, including types, fields, and relationships. Types define the structure of the data, while fields define the specific data points within a type. Relationships define how different types are connected. Understanding the schema is essential for building and securing GraphQL APIs.

The schema acts as a contract between the client and the server, ensuring that both parties have a clear understanding of the data structure. This contract helps in validating the queries and mutations, ensuring that only valid operations are executed. By defining the schema meticulously, developers can enforce strict data validation and access controls, reducing the risk of unauthorized access and data breaches.

In the next sections, we will explore common GraphQL vulnerabilities, attacks, and best practices for securing GraphQL APIs. By understanding these vulnerabilities and implementing the recommended security measures, developers can build robust and secure GraphQL APIs that stand up to the most pressing cyber threats.

Applying the OWASP API Security Top Ten to GraphQL

Now that we've looked at what the OWASP API Security Top Ten is, in this section, we'll explore each vulnerability, discuss its relevance to GraphQL requests, and provide examples and prevention strategies. The breakdown below is based on the list published in 2023.

1. Broken Object Level Authorization (BOLA)

This risk involves unauthorized access to objects due to flaws in authorization mechanisms. Due to GraphQL's single query structure, queries can expose sensitive data if proper authorization is not implemented. An example of this would be if a GraphQL query operation retrieves user profiles, including those of administrators, without adequate access checks. This would allow authorized and unauthorized users to access sensitive fields. To prevent this vulnerability, developers should implement robust authorization checks for each object, ensuring data access is adequately restricted.

2. Broken Authentication

This occurs when authentication mechanisms are implemented incorrectly, allowing attackers to compromise authentication tokens or exploit implementation flaws. With GraphQL APIs, this is particularly true given their single endpoint structure. For example, an attacker could exploit a weakly protected API key to access sensitive data via GraphQL queries. To prevent this from happening, developers should use robust and reliable authentication methods like OAuth 2.0 and regularly rotate API keys and tokens.

3. Broken Object Property Level Authorization

Combining Excessive Data Exposure and Mass Assignment from the 2019 list, this risk focuses on improper authorization at the object property level. In GraphQL, this might involve exposing or allowing modification of properties like user roles or personal data without proper checks. Prevent this by implementing strict authorization at the property level and input validation in queries and mutations.

4. Unrestricted Resource Consumption

APIs not protected with rate limiting or other resource-restricting measures can be vulnerable to DoS (Denial of Service) attacks and unlimited resource consumption. Complex GraphQL queries can consume excessive server resources, heightening this risk and leading to potential organization and financial repercussions. For example, an attacker could send a complex, nested query to overload the GraphQL server. Depending on the complexity, this could overload the server and cause a server failure, resulting in a denial of service. On the other hand, if the server is set up to auto-scale to keep up with the demand, this could lead to a massive infrastructure bill. To prevent this, developers should implement rate limiting, query complexity analysis, and query-depth limiting. Many API gateway platforms can supply this functionality for GraphQL queries.

5. Broken Function Level Authorization

This risk involves users accessing functions beyond their permissions due to misconfigured authorization. In GraphQL, the issue can arise if function-level authorizations are not correctly managed. A great example of this would be if a regular/unauthorized user accesses a mutation that should be restricted to admins. Thus allowing the unauthorized user to access a function and potentially make changes they shouldn't be able to. To prevent this, developers should rigorously define and enforce function-level permissions within GraphQL resolvers. Doing this will ensure that unauthorized function-level access is not possible, malicious or not.

6. Unrestricted Access to Sensitive Business Flows

This risk pertains to exposing business flows to excessive or automated use. In GraphQL, this could involve the API, including the resolvers that power it, allowing unchecked repetitive actions. An example of this type of exploit may be as simple as allowing a user to execute a mutation multiple times, resulting in mass account creation. To prevent this type of exploit, developers, at a minimum, should implement throttling (to prevent brute force attacks) and logic checks to control flow execution, stopping bad actors from being able to execute arbitrary commands.

7. Server Side Request Forgery (SSRF)

SSRF flaws occur when an API fetches a remote resource without validating the user-supplied URI, making it susceptible to manipulation. For instance, in a GraphQL context, if an API blindly trusts a URL input for fetching data, an attacker could manipulate this input to make the server send a request to an internal or malicious destination. To prevent SSRF, validation mechanisms must be robust, ensuring all external URLs are verified before use. It’s crucial to implement checks that confirm URLs are safe and intended for the API’s usage and to restrict the API from accessing internal resources that could be targeted in an attack.

8. Security Misconfiguration

Inadequate configurations and security settings in APIs and their infrastructure can lead to various vulnerabilities. Default or poor configurations in GraphQL, especially in error messaging, can create security loopholes and lead to breaches. For example, as with RESTful APIs, GraphQL APIs that return verbose error messages can reveal sensitive API configuration details. To prevent these security concerns, ensure secure configurations for GraphQL APIs, minimize error details returned to users, and use the appropriate security headers.

9. Improper Inventory Management

This risk involves failing to track correctly and document APIs, which is particularly relevant for GraphQL with its multiple endpoints and versions. For example, a GraphQL service might have deprecated or development-only endpoints inadvertently exposed in production. Preventing this issue requires maintaining an up-to-date inventory of all deployed API versions and actively managing them. This includes routine audits to identify and decommission outdated or unused endpoints, ensuring only current and secure versions are available.

10. Unsafe Consumption of APIs

This risk addresses the weaker security often applied to data received from third-party APIs compared to user input. In a GraphQL API, integrating a third-party service without adequate security scrutiny can introduce vulnerabilities. For instance, if a GraphQL resolver integrates data from an external API with lax security, it could lead to data breaches or other security issues. To mitigate this, treat all data from external APIs with the same rigorous security standards as user input, including thorough validation and sanitization.

In this section, we’ve done a deep dive into the OWASP Top 10 vulnerabilities in the context of GraphQL APIs. By understanding these vulnerabilities, including their OWASP definitions, specific relevance to GraphQL, examples, and prevention strategies, developers and security professionals can better secure their GraphQL endpoints.

How StackHawk Can Help!

In the landscape of API security, tools like StackHawk have become indispensable for developers, especially when securing GraphQL APIs. StackHawk is a dynamic application security testing (DAST) tool designed to identify and rectify security issues in APIs. While it supports various types of APIs, it’s particularly adept at handling the unique challenges GraphQL poses.

One of StackHawk’s key strengths is its ability to automate security testing. This automation streamlines finding vulnerabilities in GraphQL APIs, seamlessly integrating security into the regular development workflow. Tailored to the distinct nature of GraphQL, StackHawk offers specialized testing capabilities that work with GraphQL schemas, enabling it to test the API intelligently. These tests help to uncover issues that might be overlooked by tools designed for more traditional REST APIs.

When it comes to addressing the OWASP Top 10 vulnerabilities, StackHawk offers broad coverage. Its testing capabilities can detect various security vulnerabilities, including many from the OWASP list. Once the platform detects an issue, StackHawk provides in-depth insights and actionable recommendations for each vulnerability. This level of detail is crucial for developers to not only understand the vulnerabilities but also to fix them in their code effectively.

StackHawk’s developer-centric approach means it easily integrates into CI/CD pipelines, allowing for regular and automated scanning of GraphQL APIs. This integration ensures a continuous security assessment of your APIS, helping teams to identify and address vulnerabilities early in the development cycle. StackHawk’s user-friendly interface and reports help make security accessible for developers with varying security expertise.

Conclusion

As we wrap up our exploration of applying the OWASP API Security Top 10 to GraphQL, it’s clear that understanding and mitigating these vulnerabilities is vital for anyone implementing GraphQL APIs. This blog has highlighted that while GraphQL brings unique advantages in API design, it also requires specialized attention to security, particularly in areas outlined by the OWASP Top 10.

Throughout this blog, we have underscored the importance of proactive measures and modern security tools like StackHawk. With its automated, GraphQL-focused capabilities, StackHawk equips developers to integrate security testing into their workflow seamlessly. Using StackHawk ensures that GraphQL APIs are robust and secure against the most pressing cyber threats.

In conclusion, embracing tools like StackHawk and staying informed about security best practices are key steps towards securing GraphQL APIs. By diligently applying the insights from the OWASP API Security Top 10, developers and security professionals can ensure their APIs are protected against vulnerabilities, paving the way for safer and more resilient API portfolio that includes GraphQL.

7 Best DAST Tools of 2024

StackHawk

Safeguarding web applications is a top priority for any organization. As businesses increasingly rely on digital platforms, proactively identifying and mitigating security vulnerabilities has become a critical component of managing their security posture. This is where Dynamic Application Security Testing (DAST)comes into play. Selecting the correct tools to augment your existing security measures can have a major impact.

In this article, we’ll highlight the top 8 DAST tools that can elevate your cybersecurity strategy. Whether you’re looking for robust API support, seamless CI/CD integration, or powerful vulnerability scanning, these tools offer a range of solutions to help secure your applications and protect your business from the ever-evolving threat landscape.

What is DAST?

Dynamic Application Security Testing (DAST) is a key approach to identify vulnerabilities in web apps. DAST tools operate by simulating real-world attacks while the applications are running in production. By continuously scanning for vulnerabilities, DAST security tools detect weaknesses in the application’s defenses and immediately alert the development team for remediation.

As a critical component of any organization's security stack, DAST helps protect web applications and APIs, ensuring that potential threats are identified and addressed before they can be exploited.

How does a DAST Tool Work?

DAST tools excel at mimicking real-world attacks by actively probing running applications for vulnerabilities that might otherwise remain hidden.

By sending traffic and testing various inputs, they simulate a real attacker's approach, revealing weaknesses such as SQL injection and cross-site scripting, among other application security vulnerabilities. Their ability to crawl web pages and analyze application behavior without requiring access to source code makes them a versatile and valuable tool for security assessments.

A DAST solution not only facilitates further approaches and internal solutions but also offers comprehensive benefits. The detailed reports generated by DAST tools are instrumental in everything from ensuring regulatory compliance to guiding remediation efforts. Thus, DAST should be considered a comprehensive testing solution, rather than a narrowly focused toolset. Automated tools thrive on data-driven insights, and DAST solutions excel in providing this crucial information.

DAST vs. SAST

DAST (Dynamic Application Security Testing) and SAST (Static Application Security Testing) are two complementary methods used to assess application security. The primary distinction between them is that DAST examines the application from an external perspective during runtime, employing simulated real-world attack vectors focused on the live environment. Conversely, SAST involves analyzing the source code or binaries internally, without executing the application.

Typically, DAST and SAST are conducted at different phases of the software lifecycle: DAST during production and SAST during development. This timing affects their focus areas, with DAST targeting runtime issues like SQL injection and cross-site scripting, while SAST focuses on hardcoded issues and code-level security vulnerabilities.

Benefits of Using DAST Tools

DAST's strength lies in its ability to pinpoint runtime vulnerabilities, simulating real-world attacks to reveal weaknesses that other security solutions might miss. By complementing existing security measures, DAST elevates an organization's overall security posture and aids in compliance efforts. Keeping this in perspective, let's examine some benefits that DAST provides.

Vulnerability Identification: DAST tools identify runtime vulnerabilities, simulate real-world attacks, complement other testing methods (such as static application security testing), improve overall security posture, and aid compliance efforts.
Real-Time Analysis: DAST tools scrutinize applications in their operational state, identifying vulnerabilities that emerge only when the application is active. This can help detect things like server configuration issues through the identification of potential symptoms.
Technology Agnostic: DAST is independent of the programming language or technology stack.
No Source Code Required: DAST does not require access to an application’s source code.
CI/CD Integration: DAST can be integrated into Continuous Integration/Continuous Deployment pipelines.

Key Factors to Consider in DAST Tooling

Dynamic Application Security Testing (DAST) tools play a crucial role in identifying vulnerabilities by interacting with a running application in real-time. Unlike Static Application Security Testing (SAST), DAST tools simulate real-world attacks, mimicking an attacker’s approach to uncover security flaws.

By crawling through an application's web pages and testing various inputs, these tools identify vulnerabilities without needing access to the source code, instead focusing on the application’s behavior and responses. This makes DAST an essential part of securing modern web applications. Below are a few key features that you should keep an eye out for when evaluating DAST tools that you might want to use in your environment:

Continuous scanning and reporting
Simulated attacks and vulnerability detection
Integration with development workflows
Scalability and flexibility
Support for multiple platforms and technologies
Customized reporting solutions
CXO-friendly dashboards
Workflow integrations

Challenges and Limitations of DAST

While Dynamic Application Security Testing (DAST) is a powerful tool for uncovering security vulnerabilities, it does have some limitations that users should be aware of. Since DAST requires a fully functional application, it is not typically effective during the early stages of development.

Additionally, like many automated security tools, it may produce false positives or miss certain vulnerabilities altogether. DAST focuses primarily on external, web-facing vulnerabilities and offers limited visibility into the underlying code issues causing them. Below are some of the key challenges to think about when selecting your DAST tooling:

Limited Early Detection: DAST requires a fully functional version of the application. This creates a "chicken or egg" dilemma, where the question arises: should the testing process precede the completion of the web application, even if the latter is constructed with inherent issues in its core structure? This challenge reflects both a process issue and a conceptual issue with DAST, which can be mitigated through effective iterative lifecycle management and consistent testing routines.
Potential for False Positives/Negatives: Like any automated vulnerability scanning tool, DAST might produce false positives or overlook certain vulnerabilities. This inherent limitation is common to all automated scanning solutions and necessitates a multi-layered review and awareness strategy to ensure that DAST outputs are interpreted and utilized effectively.
Scope of Testing: DAST is primarily geared towards identifying vulnerabilities present in web interfaces, effectively detecting issues such as cross-site request forgery or insecure server configurations. However, it may not capture vulnerabilities accessible through non-web interfaces or alternative access paths.
Limited Insight into Code Issues: Operating from an external viewpoint, DAST provides restricted insights into the specific lines of code or lapses in code security that lead to vulnerabilities. These potential vulnerabilities are challenging to identify or translate into comprehensive remediation guidance, prompting providers to explore supplementary scanning tools for those scenarios.

Choosing the Right DAST Tool

To make an informed decision, assess your organization's unique needs, current tools, desired integrations, required features, and the technical proficiency of the team analyzing the outputs from your selected tool(s).

Consider your organization's unique requirements, such as the applications to be tested and the necessary security level. Develop a deep understanding of your current web servers and their interactions to effectively tailor your DAST strategy.

Evaluate the features and capabilities of various DAST tools, including their ability to integrate with your development workflows and provide customized reporting solutions. It's important to remember that DAST tools are essentially simulation tools - they can find exploitable vulnerabilities by simulating real-world attacks, but they are best paired with security scans from other toolsets and scanning solutions.

Therefore, an effective DAST should not only detect web application vulnerabilities but also seamlessly communicate these findings to other systems and tools. In essence, DAST tooling needs to be both efficient in detection and excel in integration with other systems.

Finally, consider the reputation and experience of the vendor, as well as the level of support and training they offer.

Top 7 DAST Security Tools for Enhanced Cybersecurity

When it comes to securing your applications, choosing the right DAST tool can make all the difference. With so many options available, each offering various features and capabilities, it’s important to understand which tools are best suited for your specific needs.

In this section, we’ll explore the top 8 DAST scanners, highlighting their key strengths and how they can enhance your security testing efforts. Whether you’re focused on the ease of integration, advanced reporting, or comprehensive vulnerability coverage, these tools offer a range of solutions designed to protect your applications from evolving threats.

1. StackHawk

Founded with a focus on a developer-friendly approach to DAST, StackHawk has quickly become a go-to for teams integrating security into their DevOps workflows. It distinguishes itself with a robust API and an interface that makes it easy for developers to incorporate web application security testing into their routines. On top of this, it is one of the only DAST platforms that support comprehensive API testing for REST, GraphQL, SOAP, and gRPC-based APIs.

The platform truly excels with its developer-centric design, providing robust reporting capabilities that empower developers to easily track and analyze results. Its seamless integration into CI/CD pipelines ensures testing becomes a natural part of the development workflow. The extensive API support is a standout feature, making the platform adaptable to a wide range of modern testing needs, from API testing to complex integrations.

The interface is user-friendly yet designed with technical users in mind. Consequently, individuals without a development background may encounter a slight learning curve. Nevertheless, the platform's potent features and capacity to streamline testing processes render it an invaluable asset for teams prepared to dedicate the necessary time and resources to become proficient with it.

2. Invicti

Invicti, formerly known as Netsparker, is a well-known platform that provides precise vulnerability scanning. It is particularly noted for its Proof-Based Scanning technology, which automatically verifies identified vulnerabilities, thereby saving time and helping to minimize false positives.

Invicti's advantages lie in its proof-based scanning technology, delivering accuracy that instills confidence in security teams, enabling them to effectively identify and neutralize threats. Its comprehensive scanning capabilities, encompassing everything from vulnerability detection to compliance checks, make it a versatile solution adaptable to a wide range of security needs. The platform's scalability and robust features make it an ideal choice for large enterprises grappling with complex security requirements.

While the platform stands out for its robust features and accuracy, but the costs may be prohibitive for smaller organizations with tight budgets. Furthermore, some users have reportedly experienced a cumbersome initial setup process that may require extra time and technical know-how.

3. Acunetix

Acunetix has been a leader in the DAST space—known for its speed and advanced scanning technology. It is adept at handling complex web applications and detecting intricate vulnerabilities, making it a favorite for fast-paced tech environments.

The core strength of Acunetix lies in its lightning-fast scanning capabilities, ensuring that vulnerabilities are identified and addressed quickly enough to keep pace with development. It excels at uncovering more complex vulnerabilities, providing a level of security that will be required in the face of evolving threats. Furthermore, its user-friendly design helps overcome technical barriers, making it accessible to security professionals and developers alike.

The platform's speed and accuracy are notable, but its premium pricing places it in a higher cost bracket that could be challenging for smaller organizations with tight budgets. Additionally, some users have reported a higher-than-desired rate of false positives. This can result in extra investigative work and manual review, leading to frustration as vulnerabilities pile up and valuable time is lost.

4. BurpSuite

BurpSuite by PortSwigger is a comprehensive set of tools for security testing. It's a blend of automated and manual testing tools, highly valued by security professionals for its depth and flexibility in penetration testing.

Burp Suite is favored by seasoned engineers and penetration testers for its ability to facilitate comprehensive analyses and reveal concealed vulnerabilities. It also allows users to create proof of concept tests by exploiting potential weaknesses. The platform’s strong community and extensibility greatly augment its capabilities, promoting a collaborative space where knowledge and tools are freely exchanged. For practitioners involved in both manual and automated penetration testing, Burp Suite shines as an outstanding option, providing the versatility and depth needed for meticulous assessments.

The platform’s comprehensive nature is an asset for experienced users; however, it can be quite overwhelming for beginners trying to navigate its vast array of features. Certain aspects of the platform require in-depth security knowledge and previous experience with Burp to be leveraged effectively, potentially limiting its accessibility for those new to the field. Despite a somewhat nuanced UI and a wide array of plugins that might challenge beginners, for seasoned professionals seeking a powerful and adaptable tool, the platform’s benefits far outweigh its learning curve.

5. GitLab

GitLab, primarily known for its comprehensive coverage as a DevOps platform, incorporates DAST into its integrated security testing suite. Its one-stop-shop nature appeals to teams looking for cohesive development and security solutions and are already running within the GitLab ecosystem.

Gitlab, as part of its integration into a comprehensive DevOps platform, also offers DAST, acting as a unified toolset that streamlines workflows and enhances collaboration. For teams already leveraging GitLab for development, this integration proves particularly valuable, creating a cohesive environment where security and development seamlessly coexist.

While the platform's DAST capabilities provide convenience within the GitLab ecosystem, they may not be as extensive as those found in specialized tools. Moreover, its full potential is realized only by users already committed to the GitLab ecosystem, limiting its appeal to those in search of a standalone security solution. However, for teams deeply invested in GitLab, the platform's integration and workflow benefits make it a compelling addition to their security arsenal.

6. Bright Security

Bright Security, formerly NeuraLegion, focuses on automating security testing in the early stages of the software development lifecycle. Offering various approaches to testing, its ease of use and integration capabilities make it a good fit for Agile and DevOps-focused teams.

Bright distinguishes itself with a clear emphasis on early-stage testing automation, empowering agile teams to seamlessly integrate security into their development workflows. Its user-friendly interface further facilitates adoption, ensuring that developers of all skill levels can readily contribute to security efforts. The platform's strong integration with CI/CD pipelines adds another layer of efficiency, enabling continuous security testing throughout the development lifecycle.

Bright offers a solid foundation for DAST, but it may lack some of the advanced features found in more established tools. Additionally, as a newer entrant in the market, it may not have the same level of recognition or experienced user base as its more seasoned competitors. However, for organizations prioritizing early-stage testing automation and ease of use within agile environments, Bright presents a compelling option.

7. Checkmarx

Checkmarx is a comprehensive application security platform offering a powerful scanning engine and broad integration capabilities. It provides a holistic view of security, ideal for organizations with complex and multifaceted security requirements.

Checkmarx's secret weapon lies in its powerful scanning engine, capable of uncovering vulnerabilities across vast and intricate codebases. Adding to its merits, extensive integration with a wide array of development tools ensures a seamless fit within existing workflows, promoting security as an integral part of the development process. For large-scale, complex environments, Checkmarx emerges as an ideal solution, offering the robustness and scalability required to maintain a high level of security.

While Checkmarx's power and versatility are proven assets, its complexity may prove overwhelming for smaller organizations or those with less extensive security needs. Moreover, harnessing the full potential of Checkmarx (much like with Burp) often necessitates a significant upfront investment in training and setup, potentially presenting a challenge for teams with limited resources or small security teams. However, for enterprises seeking a comprehensive and robust security solution capable of tackling the most demanding environments, Checkmarx's strengths far outweigh its initial hurdles.

As can be seen, each DAST tool comes with its unique set of strengths and challenges. When selecting a DAST tool, organizations need to evaluate how its specific features match their development team's size, expertise, and security priorities. Considerations such as the types of sensitive data collection, the needs for a graphical user interface versus a command line interface, and even the long-term development timeline for each solution should come into play. The right tool should integrate seamlessly into existing processes, enabling developers to enhance software security effectively.

With that in mind, below is a quick reference chart summarizing the strengths and weaknesses of the solutions we have reviewed:

Conclusion

DAST tools are indispensable in a comprehensive security testing strategy by pinpointing vulnerabilities in applications before they become targets for attackers.

Among the leading DAST tools, each offers distinct features and capabilities, catering to the diverse requirements of organizations of all sizes. The key to bolstering your cybersecurity initiatives is selecting an application security testing solution that not only boasts advanced features but also seamlessly integrates with your development processes, aligns with your security objectives, and fits within your budget constraints.

With robust API support and user-friendly tools, StackHawk can help your team find and fix vulnerabilities quickly and efficiently. But don’t just take our word for it; see what others have to say about us: StackHawk Secures Top Honor in The 2024 Global Infosec Awards at RSA.

If you're looking to enhance your security measures, explore our detailed guide on how StackHawk works. Discover how StackHawk can integrate into your security strategy and begin safeguarding your applications today!

Understanding The 2023 OWASP API Top 10 Security Risks

Matt Tanner

For many security providers, OWASP is a go-to source. The OWASP Foundation plays a crucial role in identifying critical API-specific security risks, providing guidance to strengthen API security practices. As APIs have become more prevalent and widely adopted, the OWASP Top 10 API Security Risks report - a dedicated list of vulnerabilities to watch out for aimed at those building and maintaining APIs - has become a reference guide for some of the most common missteps and failures across the board.

In this blog, we will dig into the history of OWASP and the Top 10 API Security Risks and how they’ve changed since the inaugural report in 2019. Then, we will take an in-depth look at each of the vulnerabilities listed in the 2023 report, covering what they are, why they are significant, and how to prevent them from occurring.

To kick things off, let’s start by looking at the organization behind the report: OWASP.

What is OWASP?

The Open Web Application Security Project (OWASP) is a non-profit organization dedicated to improving software security. If you’ve taken a class in application security or heard anyone talk about it, chances are you’ve heard their name floating around.

Founded in 2001, OWASP operates under an open community model, where security experts, developers, and technologists collaborate to create massive amounts of material on application security. Most of these materials revolve around articles, methodologies, documentation, tools, and technologies in web application security.

OWASP is best known for its OWASP Top 10, a standard awareness document that helps developers and organizations understand the most critical security risks facing web applications. This list, regularly updated based on evolving threats and industry consensus, is a popular guideline for organizations and developers looking to understand and mitigate common security vulnerabilities.

OWASP's resources are designed to be accessible and beneficial for various stakeholders in the software development and security fields, promoting informed and secure software development practices globally.

What is the OWASP Top 10 API Security Risks (2023 Edition)

Although OWASP is known for its more widely applicable Top 10 report, the OWASP Top 10 API Security Risks report is a document solely focused on API security. Building on OWASP’s long-standing expertise in web application security, this report specifically addresses the unique challenges and risks associated with Application Programming Interfaces (APIs).

The list identifies and ranks the top ten most critical security risks API developers face today. Developed through industry-wide surveys, expert input, and community feedback, the report offers a comprehensive overview of crucial API vulnerabilities. Vulnerabilities in API security can be exploited to gain access to sensitive data through techniques like Excessive Data Exposure and Mass Assignment. Also included in the top 10 report are real-world examples of each vulnerability and strategies for mitigation.

The first edition of the OWASP Top 10 API Security Risks report was released in 2019. This inaugural edition marked a significant shift in focus towards the unique security challenges presented by APIs. OWASP developed the 2019 report in response to the rapidly increasing use of APIs in modern software development and the corresponding rise in security vulnerabilities related explicitly to APIs.

In June 2023, OWASP issued the first significant update to their initial API Security Top 10 list. Over the four years since its initial release, OWASP has collected data and feedback reflecting the evolving landscape of API security threats and the latest industry practices, applying this learning to a significantly updated Top 10 list. The 2023 edition of the report provides a comprehensive and up-to-date overview of the most critical API security risks - and it provides some critical updates to reflect the ever-changing landscape of API security.

What Has Changed Since the 2019 Report?

The changes between the OWASP Top 10 API Security Risks reports of 2019 and 2023 reflect the evolving landscape of API security threats and industry practices. Of course, some staples of the list have not changed. The entries on the list that have remained unchanged include:

1 - Broken Object Level Authorization
2 - Broken Authentication
5 - Broken Function Level Authorization
7 - Security Misconfiguration
9 - Improper Assets Management

Other than these five, which have remained the same, others have changed entirely or been significantly updated. Let’s take a look at the latest updates.

3 - Excessive Data Exposure (2019) to Broken Object Property Level Authorization (2023)

In the 2023 report, OWASP has combined the previously separate 2019 risks of Excessive Data Exposure and Mass Assignment into a new category, Broken Object Property Level Authorization. This reflects how providers have shifted towards a more nuanced approach to authorization, emphasizing the importance of fine-grained access control at the object property level. It addresses vulnerabilities where users access data they shouldn’t, either seeing or updating it, due to inadequate control of object properties.

4 - Lack of Resources & Rate Limiting (2019) to Unrestricted Resource Consumption (2023)

The 2023 report renamed this risk to emphasize the broader impact of unregulated resource consumption. This change highlights the critical need to limit API requests to prevent crashes, resource depletion, or high operational costs due to autoscaling.

6 - Mass Assignment (2019) to Server Side Request Forgery (SSRF) (2023)

SSRF was introduced as a new risk category in 2023, replacing Mass Assignment. The inclusion of SSRF as a top risk reflects the growing concern over attacks where an API is tricked into sending malicious requests to internal systems or servers. This threat is increasingly becoming more common.

8 - Injection (2019) to Lack of Protection From Automated Threats (2023)

The 2023 report replaced Injection with a focus on protection against automated threats. This update underscores the importance of defending APIs against automated attacks like bots, scripts, and credential stuffing. The update makes sense as these attacks become more prevalent and damaging without GUI-based defenses like those in web applications.

10 - Insufficient Logging & Monitoring (2019) to Unsafe Consumption of APIs (2023)

Lastly, the 2023 report introduced Unsafe Consumption of APIs, replacing the 2019 focus on logging and monitoring. This is spurred by the growing awareness of the risks of unquestioningly trusting data from third-party APIs. It underscores the necessity for rigorous validation of all data received from APIs, acknowledging that even reputable sources can be compromised.

Changes Reflect Complexity

These changes in the OWASP report from 2019 to 2023 highlight the massive changes that API developers have experienced in just over four years. These updates align with the increasing complexity and integration of APIs in modern applications, signaling critical areas for security focus and improvement.

Methodology Behind the OWASP API Top 10

As with any collated list of potential risks, the methodology is as important as the findings. OWASP builds its list through a comprehensive approach, joining data from many sources. While there is plenty of reported data in the form of vulnerability reports and disclosures, OWASP also benefits from a significant open-source contribution from various vendors, consultant groups, bug bounty reports, and organizational efforts. This ultimately results in a list that reflects both the publicly available data and the data typically reserved within closed-source or first-party reporting.

Importantly, OWASP maintains its non-profit and independent status. Although it does benefit from sponsorships, its data is platform and solution agnostic. In other words, if a weakness is present, it is reported. This has made the top ten list a trusted source for many providers.

Detailed Explanation of OWASP API Top 10

Finally, we have arrived at the entire list, updates, and all. In this next section, we will cover all ten vulnerabilities that OWASP has outlined. For each, we will cover what the vulnerability is and a brief example. We will also go over the consequences of not defending against such vulnerabilities, as well as how to prevent them.

Broken Object Level Authorization

This risk involves insufficient authorization checks when an API handles object identifiers, potentially allowing unauthorized access. An example would be if a user manipulates the ID in the URL to access another user's data. The consequence of having this type of vulnerability exploited is that attackers could gain unauthorized access to data, leading to data breaches and privacy violations. To prevent this type of exploit, you’ll want to implement robust and consistent object-level authorization checks across all API endpoints.

Broken Authentication

This occurs when authentication mechanisms are implemented incorrectly, potentially allowing attackers to compromise authentication tokens or user identities. An example of this would be if an authentication mechanism will enable attackers to use stolen tokens to impersonate a legitimate user. If broken authentication is in place, this could lead to unauthorized access, data breaches, and account takeovers. To ensure that your APIs don’t succumb to this type of exploit, you should use multi-factor authentication, secure token handling, and regular updates to authentication mechanisms.

Broken Object Property Level Authorization

This risk arises from inadequate or missing authorization checks at the object property level, leading to information exposure or manipulation. For example, this type of exploit happens when an attacker modifies an object property they shouldn't have access to, like changing the role property from 'user' to 'admin'. If this vulnerability is exploited within your APIs, you could expect to see unauthorized data manipulation and the risk of information leakage. To prevent this, you should implement fine-grained access control and validate authorization at the property level.

Unrestricted Resource Consumption

This involves API requests consuming excessive resources, leading to potential service disruption. A typical example of this would be when an attacker sends numerous complex requests to exhaust server resources, causing a denial of service. The apparent consequence of this type of exploit would be a Denial of Service attack, and since more resources are consumed, you could expect increased operational costs. The simplest way to prevent this type of attack is to implement rate limiting and quotas for each endpoint and enforce efficient resource management and monitoring for spikes.

Broken Function Level Authorization

This occurs when there are flaws in function-level access controls, potentially allowing unauthorized access to functions. This risk is embodied in scenarios such as when a regular user accesses administrative functions due to poorly implemented access controls. If users can access certain functions because of broken function level authorization, this might lead to unauthorized actions being performed and data breaches. To prevent this, ensure a clear separation of user roles and robust access control policies.

Unrestricted Access to Sensitive Business Flows

This exploit relates to when APIs expose business logic without adequate controls, leading to abuse or misuse. An example of this might be if someone uses automated scripts excessively using a 'free trial' feature. If allowed, you can expect the business logic to be abused, impacting operations and increasing costs. To prevent this type of behavior, developers should aim to implement business logic rate limiting and abuse detection mechanisms.

Server Side Request Forgery (SSRF)

This occurs when an API fetches a remote resource based on a user supplied URL without proper validation, leading to security vulnerabilities associated with Server Side Request Forgery (SSRF). A typical execution of this attack involves attackers tricking the server into making requests to internal services within the organization’s infrastructure. This might lead to internal network exposure and data breaches. To prevent this from happening, APIs should validate and sanitize all user-supplied URIs and restrict outbound requests.

Security Misconfiguration

This involves insecure default configurations, incomplete setups, or misconfigured HTTP headers. A common form of this issue is when an API server can be accessed with default credentials or when verbose error messages expose sensitive user data. This can lead to unauthorized access and data leakage. To prevent this from happening, developers should regularly review and update configurations and follow security best practices.

Improper Inventory Management

This happens when developers and their organizations fail to maintain an accurate inventory of deployed API versions and endpoints. An example of where this can cause issues is when outdated API versions remain operational and accessible, containing known (and unknown) vulnerabilities. The risk here is the possible exploitation of outdated or deprecated APIs. To prevent this, organizations should maintain a thorough and up-to-date inventory of all API endpoints and versions.

Unsafe Consumption of APIs

This involves insufficient validation or security checks when consuming third-party APIs. An example would be when a user trusts data from a third-party API without validation, leading to malicious data from the third-party API being processed. If allowed, it could lead to data corruption and security breaches through third-party integrations. To stop this from happening, developers should apply robust security checks and validations for all data received from third-party APIs.

Key Takeaways and Recommendations

The OWASP report provides several key takeaways that providers should consider.

First and foremost, OWASP points towards proactive efforts as a stronger solution than mitigation. Many of the problems on the top ten list are problems that exist because of lacking awareness or detail oriented thinking - for that reason, simple issues such as Broken Object Level Authorization, or BOLA, are surfaced alongside recommendations for better controls, checks on implementation, and overall observability of the platform.

Secondly, OWASP makes a point to suggest an awareness of - and in many cases, reduction of - the amount of data that is being exposed by an API. Overly verbose systems are easier to crack, and while simple misconfigurations are frighteningly common, it is the verbosity of the platform and the surfacing of attack vectors which compounds their threats so significantly.

The OWASP top ten list makes it clear that shifting left is the best policy for security in 2024. Integrating security early on in the life of a project and engaging in regular testing and validation is incredibly important, as is higher quality and more consistent education on the resultant risks of failing to adopt this strategy. APIs are the backbone of the modern internet, and in many ways - although OWASP doesn't say it in so many words - security needs to "level up" in many organizations and be taken as the much more critical facet that it actually is.

Conclusion

With that, we’ve done an in-depth exploration of the latest updates to the OWASP Top 10 API Security Risks. We’ve looked at the changes since the edition released in 2019 and reviewed the latest 2023 list from top to bottom.

To prevent these risks from impacting your APIs and operations, you’ll need the right toolkit as a developer. These exploits must often be stopped well before they can hit production. To do this, it makes sense to find and remedy these as early as possible when code is being written. Using a tool like StackHawk, users can test their APIs and applications to detect many of the OWASP API Top Ten Security Risks mentioned in the list.

By running StackHawk in your CI/CD flow, your code is tested in its running state, reporting potential vulnerabilities. Developers can then be aware of any vulnerabilities and fix them before they can be exploited. Want to know more about how StackHawk works? Check out the blog here. Sign up for a free trial today to try out StackHawk for yourself and protect your APIs against the OWASP Top 10!

Mastering GraphQL Security: A Comprehensive Guide

Nicole Jones

Introduction

GraphQL Application Programming Interfaces (APIs) have become a relatively common way to implement APIs for modern applications. As GraphQL has become more prominent, it has become an important technology for data communication and exchange between applications, ranging from complex transactions in global financial systems to nuanced interactions within smartphone apps. The significance of GraphQL APIs goes beyond their functionality; they are critically important in protecting sensitive data and systems from cyber threats. With the increasing adoption and complexity of GraphQL APIs, the urgency to secure them effectively is more critical than ever.

This guide will look at the various aspects of GraphQL API security, providing you with the knowledge required to safeguard your APIs against a wide array of potential threats. Understanding different GraphQL implementations and their security implications is crucial. We will delve into the intricate layers of GraphQL API security, from foundational principles to advanced protective strategies, ensuring the integrity and confidentiality of your users’ digital interactions are maintained securely. Testing GraphQL queries for vulnerabilities is necessary to prevent potential security risks. Covering everything from the basics of securing traditional APIs to the unique challenges of GraphQL, this guide presents the most effective and up-to-date best practices for securing your GraphQL APIs. Let's begin by looking at the fundamentals of GraphQL and GraphQL security.

Introduction to GraphQL Security

What is GraphQL?

GraphQL is a powerful query language for APIs that allows clients to request exactly the data they need, no more and no less. Unlike traditional REST APIs, which often require multiple endpoints to fetch related data, GraphQL provides a single endpoint that clients can use to query multiple resources in one request. This flexibility makes GraphQL an efficient tool for building APIs, as it reduces the amount of data transferred over the network and minimizes the number of requests needed to fetch related data.

For example, a REST API might require two separate requests to different endpoints to fetch a user's profile and recent posts. In contrast, a GraphQL API can handle this with a single query, specifying the exact fields and relationships needed. This not only improves performance but also simplifies the client-side code.

GraphQL vs. REST

When comparing GraphQL to REST, data fetching efficiency is one of the most significant advantages GraphQL brings to the table. In REST, clients often receive more data than they need, leading to over-fetching, or they might need to make multiple requests to get all the required data, leading to under-fetching. GraphQL addresses these issues by allowing clients to specify precisely what data they need in a single request.

For instance, if a client only needs a user’s name and email, a GraphQL query can request just those fields, avoiding the unnecessary transfer of additional data like the user’s address or phone number. This level of granularity and control over data fetching makes GraphQL a preferred choice for many developers.

Moreover, GraphQL’s flexibility extends to its ability to evolve APIs without versioning. In REST, changes to the API often require versioning, which can lead to maintenance challenges. GraphQL, however, allows for the addition of new fields and types without affecting existing queries, providing a more seamless API evolution.

What is API Security?

As applied to GraphQL, API security is the crucial barrier between your GraphQL APIs and the complex array of threats in today’s interconnected digital ecosystem. It encompasses various aspects, including multiple protocols, systems, and tools, each specifically designed to prevent and evade malicious attacks on or through GraphQL APIs, thereby safeguarding the essential components of modern software communication.

At its most basic, GraphQL API security ensures that only authorized users can execute authorized actions. This typically involves implementing robust authentication and authorization processes to verify user identities and manage access permissions. Encryption also plays a pivotal role in GraphQL API security as a critical mechanism to protect data during its transfer between servers and clients. However, protection for GraphQL APIs extends beyond access control; it includes monitoring and logging API activities to identify and neutralize potential threats, implementing rate limiting to curb abuse, and managing the lifecycle of the GraphQL API to reduce exploitable vulnerabilities. Understanding and mitigating GraphQL attacks is crucial for maintaining the security of GraphQL APIs, as these attacks can lead to unauthorized data access and information disclosure due to flaws in API configurations.

It is also crucial to secure the GraphQL endpoint, as Cross-Site Request Forgery (CSRF) vulnerabilities can arise from certain request methods not being validated by the GraphQL endpoint.

Unlike other software development processes, GraphQL API security is not a one-time task but a continuous process. It needs to evolve in response to the changing threat landscape and adapt to the unique characteristics and integration patterns of GraphQL APIs. The ultimate aim is to foster a secure data exchange environment that maintains data integrity, availability, and confidentiality while minimizing potential attack surfaces.

Why is API Security Important?

The critical role of GraphQL APIs in modern software and applications brings with it significant risks. Given their exposure to the open internet, GraphQL APIs are inherently vulnerable to cyberattacks. The importance of GraphQL API security is rooted in the necessity to protect sensitive data transferred between services, maintain user privacy, and prevent disruptions in business operations by malicious actors.

The consequences of API security breaches have been starkly highlighted in recent years. Such incidents can result in data theft, service outages, and substantial financial losses. For example, an unprotected GraphQL API could be exploited by an attacker to access sensitive customer information, leading to identity theft and fraud. Attackers can exploit authorization flaws by manipulating the following query to access sensitive data. While data breaches are often associated with compromised databases, the potential for data leaks through APIs, especially those as dynamic as GraphQL, is equally significant.

API security is a critical component of users’ trust in digital services. A breach in a GraphQL API can severely damage a company’s reputation, eroding customer trust and loyalty. Moreover, due to the interconnected nature of services, a vulnerability in one GraphQL API can have cascading effects, impacting associated services and partners and amplifying the overall damage of the breach.

Therefore, securing GraphQL APIs is not merely a technical requirement but a crucial business imperative. Establishing a robust security framework for GraphQL APIs is essential to provide users with a secure and reliable service and comply with regulatory standards such as GDPR and HIPAA.

Understanding GraphQL Vulnerabilities

GraphQL API Vulnerabilities and Common Attack Examples

GraphQL APIs, while powerful and flexible, are not immune to security vulnerabilities. Understanding these vulnerabilities is crucial for building secure APIs. Some common attack vectors include brute force attacks, malicious queries, and batch multiple queries.

Brute Force Attacks: These attacks involve sending a high volume of queries to the API in a short period, aiming to overwhelm the server and degrade its performance. Attackers may use automated tools to send multiple queries rapidly, attempting to find vulnerabilities or simply exhaust server resources.

Malicious Queries: Attackers can craft queries designed to exploit specific vulnerabilities in the API. For example, SQL injection attacks can occur if user input is not properly sanitized, allowing attackers to execute arbitrary SQL commands. Cross-site scripting (XSS) attacks can also be a risk if the API returns user-generated content without proper encoding.

Batch Multiple Queries: GraphQL’s ability to batch multiple queries in a single request can be exploited to launch denial-of-service (DoS) attacks. By sending a large number of complex queries in one request, attackers can consume significant server resources, potentially causing the server to become unresponsive.

How Do You Secure a GraphQL Endpoint?

Securing GraphQL APIs, one of the more recent advancements in API technology presents unique challenges due to its distinct query language and flexible features. Unlike REST APIs, which operate with defined endpoints and structured requests and responses, GraphQL allows clients to query precisely what they need. This flexibility introduces several security considerations that differ from traditional API models. Let's take a look at a few of the most pressing security concerns when it comes to GraphQL endpoints:

Authentication and Authorization

Firstly, implementing robust authorization and authentication is vital. It is similar to securing REST API endpoints but with added complexity in GraphQL. Authentication can follow similar REST patterns (e.g., JSON Web Tokens, OAuth 2.0, or API keys), while authorization often requires more granular control at the field and type level. Here is an example of a GraphQL endpoint written in Node, which implements some basic JWT authentication and field-level authorization:

What’s Happening Here?

We define a simple schema with two fields: publicInfo and sensitiveData.
The sensitiveData resolver checks context.user to determine if the requester is authorized. Without valid JWT credentials, access is denied.
In a real-world scenario, consider adding finer-grained authorization logic, such as role checks or attribute-based access controls.
We also disabled GraphiQL (the built-in UI) in production to reduce introspection and exposure of sensitive schema details.

Input Sanitization and Validation

Secondly, developers must rigorously validate and sanitize all inputs in GraphQL APIs to guard against malicious activities like injection attacks. Proper input validation helps prevent risks like Cross-Site Scripting (XSS) and Server-Side Request Forgery (SSRF). Here is a simple example in Node which shows how you could implement input validation within a GraphQL mutation:

Here, the mutation checks the provided email against a simple regex. A more extensive validation or a library like validator.js could be used in a production environment.

Query Complexity, Depth, and Denial-of-Service Attacks

Managing query complexity is crucial to preventing denial-of-service (DoS) attacks caused by overly complex or nested queries. Techniques such as limiting query depth or complexity help ensure the server does not become resource-exhausted.

Although the express-graphql library does not have built-in complexity analysis, you can integrate third-party tools or apply custom logic in the middleware. Here is an example in Node of how you can control query depth limit using a third-party library, in this case, graphql-depth-limit.

This snippet uses graphql-depth-limit to restrict the nesting depth of queries to a maximum of 5 levels, helping mitigate deeply nested queries that might attempt to overwhelm the server.

Schema Introspection

Another critical step is preventing unauthorized schema introspection in production environments. Introspection can reveal sensitive details about your schema, potentially aiding attackers. The example below shows how introspection can be easily disabled for production environments within a Node implementation.

For batching attacks or multiple queries in a single request, rate limiting and throttling ensure an attacker cannot exploit these features to gain unauthorized data or degrade performance.

GraphQL API Security Best Practices

Now that we've covered the basics of GraphQL API security when it comes to the code, let's shift our focus to essential best practices for securing your APIs that extend beyond just what is implemented within the code itself. Here are nine best practices to take into consideration when implementing GraphQL.

1. Conduct Regular Security Audits and Penetration Testing

Regularly audit your GraphQL APIs and perform penetration tests to uncover and address vulnerabilities before they can be exploited. Use automated scanning tools and professional penetration testing services to simulate real-world attack scenarios.

2. Implement Authentication and Authorization

Use standard authentication protocols like OAuth 2.0, OpenID Connect, or JWT-based auth. Implement fine-grained authorization logic to ensure users and services can only access the data they are permitted to see or manipulate.

3. Encrypt Data in Transit and at Rest

Always use TLS (HTTPS) to encrypt data in transit. For data at rest, use robust encryption algorithms and secure key management. This is crucial to protecting sensitive data, such as user credentials, personal information, or financial records.

4. Effective Error Handling, Logging, and Input Validation

Ensure that error messages do not expose internal details of your schema or implementation. Maintain comprehensive logs for debugging and auditing but never log sensitive data. Validate and sanitize all inputs to thwart injection-based attacks.

5. Use Throttling, Rate Limiting, and Query Depth Limiting

Limit the number of requests per client or per IP address. Apply query depth and complexity limits to prevent resource starvation attacks. An API gateway or middleware solution can enforce these policies automatically.

6. Ensure Proper API Versioning and Deprecation Strategies

Adopt transparent versioning practices to ensure users know when changes occur. Provide a clear migration path and sunset deprecated versions responsibly, giving users time to adapt.

7. Embrace a Zero-Trust Network Model

Assume no user or system is trustworthy by default. Employ strict verification mechanisms at every layer, enforce the principle of least privilege, and segment the network for added security.

8. Automate Scanning and Testing for Vulnerabilities

Integrate vulnerability scanning into your CI/CD pipeline. Perform both static (SAST) and dynamic (DAST) checks to catch issues before they reach production, adjusting to new threats as they arise.

9. Secure the Underlying Infrastructure

Apply security best practices to servers, containers, and cloud platforms. Regularly patch, monitor for intrusions, and enforce strict firewall and network rules. Infrastructure security often complements API-level security measures.

Augmenting API Security With StackHawk

As mentioned, StackHawk is essential in reinforcing the concepts outlined above. A developer-friendly DAST solution, StackHawk automates security tests against your APIs, including GraphQL endpoints, identifying common risks like injection attacks or misconfigurations before they are deployed.

Key Benefits of StackHawk:

Automated Security Risk Tests: Quickly uncover common vulnerabilities in your GraphQL endpoints early in development.
CI/CD Integration: Seamlessly integrate into your pipeline, ensuring each code change undergoes security review.
Support for Various API Types: Test REST, SOAP, gRPC, and GraphQL endpoints all in one place.
Efficient Vulnerability Management: Gain actionable insights and remediation steps, making it easier for developers to fix issues promptly.

Testing GraphQL with StackHawk

To scan a GraphQL application with StackHawk, you'll need to:

set app.graphqlConf.enabled to true in stackhawk.yml
configure a GraphQL schema (introspection endpoint or schema file)

Here are a few configuration examples to demonstrate how easy it is to set up within StackHawk.Our first example shows how to point HawkScan to your application’s GraphQL introspection endpoint. This can be done in your stackhawk.yml file like this:

You can also import a JSON-formatted schema file into HawkScan as well. This is also done by pointing your stackhawk.yml file towards the JSON file with your endpoint definitions. That can be done like this:

Note: HawkScan requires that either schemaPath or filePath be configured. It is unusual to configure both, but it is sometimes necessary. If both filePath and schemaPath are set, the schema will be loaded from the file system, and the schemaPath will be used for requests to the API.

This configuration instructs StackHawk to perform tests, including introspection queries, against your GraphQL service. This early feedback loop helps detect misconfigurations or vulnerabilities at the earliest stages of development.

Conclusion

As we conclude our comprehensive exploration of GraphQL API security, it’s clear that protecting these APIs is critical and complex. We’ve navigated through fundamental principles, examined unique aspects of GraphQL security, and explored tools and best practices. A layered security approach is essential, from implementing robust authentication and authorization to enforcing input validation, query complexity limits, and secure error handling.

StackHawk is essential in this ecosystem, delivering automated testing that complements contemporary API architectures. Integrating StackHawk into your CI/CD pipeline guarantees ongoing testing of your GraphQL APIs, facilitates the early discovery of vulnerabilities, and streamlines the remediation process.

As you apply the knowledge gained here to your GraphQL API implementations, consider leveraging StackHawk’s free account to take proactive steps toward stronger security. Your GraphQL APIs—and the sensitive data flowing through them—will be better protected against the evolving threat landscape.

REST API Security Best Practices

Alexa Sevilla

APIs, especially REST APIs, are one of the most essential components of the software we build today. For data exchange and communication between applications, REST APIs are used in everything from high-traffic financial transactions to smartphone apps. However, REST APIs are more than just functionality; their implementation and integration are critical for securing sensitive data and systems from cyber threats. With REST APIs being used increasingly, API traffic and complexity are growing, and so is the need to secure them. To keep applications secure, developers need to implement advanced REST API security to tackle the sophisticated threats and vulnerabilities impacting apps on a daily basis.

This guide will focus on the different aspects of REST API security and give you the knowledge to protect your RESTful services from security threats. We will explore the detailed layers of REST API security, from the basics to advanced protection strategies. This comprehensive guide will provide the most effective and up-to-date best practices for securing your REST APIs. Let’s start with the basics: What is API security?

What is API Security?

A REST API security strategy is critical to protecting your RESTful APIs from the complex array of threats that exist in the wild. It encompasses various aspects, including protocols, systems, and tools to prevent malicious attacks on or through REST APIs. These components are essential in safeguarding the foundations of modern software communication that REST APIs facilitate.

At its core, REST API security ensures that only authorized users can execute authorized actions. This is primarily achieved through applying API authentication and authorization processes to each API call. These processes are crucial for verifying user identities and appropriately granting permissions. Encryption also plays a key role in API endpoint security as an essential mechanism to protect data as it travels between servers and clients. However, the scope of REST API security extends beyond just access control. It involves monitoring and logging REST API activity to identify potential threats, implementing rate limiting to prevent abuse, and managing the REST API lifecycle to reduce vulnerabilities that attackers could exploit.

REST API security is a continuous process within the software development lifecycle that requires constant attention. It must adapt to the changing threat landscape and the evolution of REST API designs and integration patterns. This means that development teams must take proactive measures, such as threat hunting and monitoring API usage. Adhering to industry standards and referencing recent security reports are crucial REST API security practices to establish a secure data exchange environment that maintains data integrity, availability, and confidentiality while minimizing the surfaces vulnerable to attacks.

Why is API Security Important?

By design, REST APIs are exposed to the open internet, making them vulnerable to attacks. REST API security is needed to protect the data being transferred between services, enhance user privacy, and prevent malicious actors from disrupting business operations through an attack.

In recent years, the consequences of security breaches in REST APIs have become more severe. These can lead to data theft, service outages, and financial losses. An unprotected REST API, for example, can allow an attacker to extract sensitive customer data and use it for identity theft and fraud. While data breaches are often associated with compromised databases, the same data can be exposed or leaked through REST APIs. Businesses face the direct impact of these breaches and regulatory penalties for not protecting user data under laws like GDPR and HIPAA.

REST API security is crucial to users' trust in digital services. A breach can damage a company’s reputation and cause a loss of customer trust and loyalty. Since REST APIs are interconnected, a vulnerability in one API can have a ripple effect, impacting other services and partners and amplifying the damage.

So, REST API security is not just a technical issue; it’s a critical part of business strategy. A well-implemented REST API security framework provides your users with a secure service and protects your business against the adverse effects of a successful API attack.

How Do You Secure a REST API?

Securing a REST API is a major task that must be undertaken at the beginning of API development. REST APIs are popular because they are simple and stateless and use standard HTTP methods. However, these characteristics can also make them vulnerable if they are not appropriately secured. Let’s examine some of the security features and patterns important for securing a RESTful API.

Transport Layer Security

Transport Layer Security (TLS) is a must for REST API security. It encrypts data between clients and servers to protect sensitive information like API keys and access tokens from being intercepted. This end-to-end encryption helps maintain data integrity and confidentiality by preventing man-in-the-middle attacks.

Tools like API gateways can simplify TLS implementation or enable mutual TLS (mTLS), which allows clients and servers to authenticate each other for extra security. By prioritizing TLS in your REST API, you reduce the risk of data breaches and user trust.

Authentication and Authorization

Authentication and authorization are essential for REST API security:

Authentication verifies the client identity, only legitimate users can access your API.
Authorization determines what actions an authenticated user can perform and restricts resource access to approved operations.

Common approaches include using an API Key, which provides a simple way to identify and track callers; OAuth 2.0, which issues short-lived, refreshable access tokens for secure access; and JSON Web Tokens (JWTs), which use signed tokens to assert a user’s identity and permissions. These access token mechanisms ensure that only authorized users can access your REST API, helping protect sensitive data and maintaining data integrity and confidentiality. Implementing scalable authentication and authorization is extremely simple with a modern API gateway.

User Input Validation

User input validation is essential to secure your REST API from common security threats. Injection attacks, such as SQL injection and cross-site scripting (XSS), occur when malicious or malformed data is sent to the API. The attacker can execute unauthorized code or access sensitive information. To mitigate these risks, you need to validate all incoming data and ensure it conforms to the expected data types and values. This involves checking the length, format, and content of user input and rejecting or sanitizing any data that does not meet the defined criteria.

A good input validation strategy can fortify your REST API by blocking malicious data before it reaches your internal logic or database. By enforcing strict input standards, such as acceptable characters or numeric ranges, you reduce the chance of unexpected behavior, data corruption, or unauthorized access. Overall, user input validation helps maintain the integrity and confidentiality of your system and protects your API from common vulnerabilities and attacks.

Security Audits and Penetration Testing

You need to test your REST API security regularly. Security audits assess your API infrastructure, policies, and codebase to ensure compliance with security standards. Penetration testing tests your API against real-world cyber-attacks. Integrating automated tools like StackHawk into your development cycle and hiring external penetration testers will give you a comprehensive view of your API security.

Encrypt Data in Transit and at Rest

Encryption is non-negotiable for REST API security when data is at rest, in addition to the security TLS offers for data in transit. For data in transit, use TLS with strong cipher suites. For data at rest, use encryption algorithms like AES and manage encryption keys with cloud providers or hardware security modules (HSMs) services.

Proper Error Handling and Logging

Proper error handling must be implemented to avoid leaking sensitive data through API errors. Uniform error responses that don’t reveal the internal workings of the API are important. Logging API transactions is vital for tracking and analyzing activities and ensuring that logs don't contain sensitive information.

Throttling and Rate Limiting

Throttling and rate limiting are essential to control the number of requests to your API, which will prevent denial-of-service attacks. Throttling controls the API’s throughput, while rate limiting imposes hard limits on API requests. Implement these through API gateways or middleware to avoid overuse and to protect against denial-of-service attacks.

Proper API Versioning and Deprecation Strategy

As you improve your API, you should have a transparent versioning and deprecation strategy. Use Semantic Versioning and communicate changes through changelogs. When deprecating older versions, give users ample notice and guidance so they can migrate to newer versions.

Zero-Trust Network Model

Adopting a zero-trust model means not trusting any user or system, even within your network perimeter. This means strict authentication and authorization verification, as well as applying the principle of least privilege and network segmentation to limit lateral movement.

Automate Scanning and Testing for Vulnerabilities

Scan and test your REST API for vulnerabilities regularly. To catch issues early, this should be an automated part of your development process, ideally in your CI/CD pipeline. Use dynamic and static application security testing tools to analyze your code and stay updated with new security threats and patches.

Secure the Underlying Infrastructure

The infrastructure hosting your API endpoints is the foundation. Regular updates, patches, strict firewall rules, and intrusion detection systems are necessary. In a cloud environment, use the security features provided by the provider and follow best practices in access and account management, especially ensuring that users are using secure passwords that are changed frequently and enforcing multi-factor authentication.

These best practices will provide a solid security framework for your REST APIs. However, always consider the specifics of your API deployment, such as regulatory requirements and the type of APIs you are managing, as there may be additional best practices to be aware of!

Augmenting API Security With StackHawk

As mentioned in our breakdown of best practices, StackHawk is pivotal in reinforcing some of the API security concepts outlined above. It is a dynamic application security testing (DAST) tool built for developers, offering a suite of automated testing capabilities that align closely with best practices for API security.

The platform is easy to use and automated, and it provides a best-in-class experience for developers to create secure APIs. Let's examine some of the benefits StackHawk offers API developers and their teams.

Automated Security Risk Tests

Integration with CI/CD Pipelines

Modern Tooling for Various API Types

Unlike other tools, StackHawk can support a wide variety of API types for testing. The tool caters to modern application architectures by supporting REST, GraphQL, SOAP, and gRPC APIs. This helps ensure that your entire API portfolio has blanket coverage instead of excluding API types that other tools may not support.

Efficient Vulnerability Management

The most powerful outcome for developers who use StackHawk is fast detection and detailed remediation documentation. StackHawk streamlines the process of fixing vulnerabilities, making developers' lives easier and the APIs they create more secure. By making the tool developer-friendly, API vulnerability management becomes easy to implement and utilize.

By incorporating StackHawk into your API development lifecycle, you can make significant progress toward maintaining a high-security standard and adhering to the best practices outlined in this guide.

Conclusion

As we wrap up our focused exploration of REST API security, the critical and complex nature of these practices is evident. This guide has guided you through the essential aspects of securing REST APIs, starting with foundational principles, including those highlighted in the OWASP API Top 10, and advancing to the strategies needed for robust REST API security. We've also discussed strategic best practices vital for strengthening your digital defenses, emphasizing their relevance in the context of REST API security.

In the ongoing journey to achieve security excellence, tools like StackHawk prove invaluable. StackHawk equips teams with the means to enhance their REST API security strategies effectively. Offering automated security testing specifically designed for modern REST APIs, seamless integration with CI/CD pipelines for early detection of vulnerabilities, and compatibility with a wide range of RESTful architectures, StackHawk ensures that your security measures keep pace with your evolving APIs.

As you aim to apply the insights from this guide to real-world security improvements, StackHawk is a great place to start helping you discover and test your APIs for potential vulnerabilities. Create a free account with StackHawk, the first step towards achieving optimal security for your REST APIs.

API Security Best Practices: The Ultimate Guide

Nicole Jones

Application Programming Interfaces (APIs) have become a staple in almost every application and software we develop. They make up the fabric of how we, as developers, communicate and exchange data between applications. From the bustling data exchanges of global financial systems to the subtle, everyday interactions within a smartphone app, APIs are core to functionality that users expect.

However, the critical role of APIs extends beyond just the functionality they provide; they are also vital to safeguarding sensitive data and systems against cyber threats. As APIs continue to boom in both usage and complexity, the imperative need to secure them has never been more critical.

This guide will explore many facets of API security to give you the knowledge to fortify your APIs against many potential security threats. This guide delves into the nuanced layers of API security, from the fundamentals to advanced protective strategies, ensuring that the integrity and confidentiality of your users' digital interactions remain secure and uncompromised.

Whether securing a RESTful service or navigating the new world of GraphQL, this guide covers the complete landscape of API security to bring you the most effective and current best practices for keeping your APIs safe. Let’s start by looking at the most fundamental of all questions: what is API security?

What is API security?

API security is the protective shield between your APIs and the multifaceted threat landscape that is the byproduct of the interconnected nature of today’s digital ecosystem. API security itself is composed of many different aspects, spanning different protocols, systems, and tools. Each of these facets is designed to prevent malicious attacks on or through APIs, helping to protect the building blocks of modern software communication.

API security ensures that only authorized users can perform authorized actions at their most basic level. This is generally achieved through implementing robust authentication and authorization processes. These processes help to confirm user identities and grant permissions appropriately. Encryption also plays a critical role here, serving as a vital tool to protect data as it moves between servers and clients.

API Monitoring and Logging

API security doesn't stop at access control; it also involves monitoring and logging API activity to detect and stop potential threats, implementing rate limiting to prevent abuse, and managing the API lifecycle to mitigate vulnerabilities that attackers could exploit.

Unlike other processes within the software development lifecycle, API security is not a one-time setup but a continual process. API security must evolve with the changing threat landscape and adapt to new types of APIs, such as what we saw with the advent of GraphQL, and the latest integration patterns. The goal is to create a secure environment for data exchange that upholds data integrity, availability, and confidentiality while minimizing the attack surface that attackers could exploit.

Why is API Security important?

With the pivotal role that APIs play in modern software and web applications, comes a significant risk; by their nature, APIs are exposed to the open internet, making them a prime target for cyberattacks. The importance of API security stems from the need to protect sensitive data transferred between services, safeguard user privacy, and ensure malicious actors do not disrupt critical business operations through an attack.

As we have seen within the last few years, the stakes of API security breaches are high. Such security incidents can lead to data theft, service outages, and significant financial losses. For instance, an unprotected API could allow an attacker to siphon off sensitive customer data, resulting in identity theft and fraud. Often, we think about databases being compromised, leading to data breaches; however, this same data can also be leaked via API.

API Breaches and International Regulations

Due to these breaches, businesses may face regulatory penalties for failing to protect user data, with many standards and penalties being outlined in protection laws like GDPR and HIPAA that govern many industries.

API security, whether users fully understand it or not, is a big part of the trust users place in digital services. A single breach can severely impact a company's reputation, causing a loss of customer trust and loyalty. Even more important is that one vulnerable API can have many ripple effects due to the interconnected fabric of different services. An example would be if a compromised API is associated with other services and partners, amplifying the impact of a breach.

Therefore, proper API security, is not just a technical necessity but a business imperative. A solid approach and framework to API security are essential to ensuring that your organization offers a secure service for your users.

How do you secure a REST API?

Securing REST APIs starts from the ground up, preferably from the outset of building said APIs. Making sure that a REST API is secure has to be approached from many different angles. REST, or Representational State Transfer, is a type of API that uses standard HTTP methods and is highly popular for its simplicity and statelessness. However, the same features that have led to the popularity of REST can be exploited if not properly secured. Let’s look at some basic security features and patterns to implement to secure a RESTful API.

Using Transport Layer Security (TLS)

Firstly, you’ll want to implement Transport Layer Security (TLS) to ensure that all data transmitted between the client and server is encrypted. One of the easiest ways to do this is to use an API gateway that allows you to use TLS, preferably mutual TLS (mTLS), if available. Utilizing TLS functionality in your REST API mitigates the risk of data interception and unauthorized access during transmission. It’s a fundamental step that forms the baseline of REST API security.

Identity Providers and JWT

Secondly, authentication mechanisms are critical and should be implemented as well. Again, any API gateway or API proxy can be used to add this functionality easily. You often use an already established identity provider (IdP) such as Okta or Auth0 to generate tokens and manage identity. API keys or, more commonly, auth tokens, such as JSON Web Tokens (JWT), are a common method for securing REST APIs.

Tokens can help to ensure that only authenticated users can access certain endpoints. These tokens can also contain scopes and permissions that can be used for authorization, ensuring that users can only perform the authorized functions. Tokens and API keys are preferred over basic authentication methods because they do not require transmitting usernames and passwords with each request, a practice that also comes with risks.

Input Validation in REST APIs

Lastly, input validation is another essential practice that should be implemented. The basic principle applied here is that REST APIs should never trust the data they receive. Many API frameworks have various mechanisms to help with this, one of the most crucial being using the correct mechanisms for any database query. Rigorous validation of all incoming data helps to prevent common vulnerabilities like SQL injection and cross-site scripting (XSS).

This involves validating the types of data and sanitizing it to ensure that malicious user input is neutralized before it has the chance to do any damage. For those using an Open API Specification (OAS), formerly known as a Swagger specification, you can also use this document to verify that incoming data matches the data type expected for each field and some other attributes. However, this should only be used as a preliminary check as a supplement to good input validation built into your code.

These foundational security measures are “must-implement” pieces for anyone creating REST APIs. Of course, many other advanced security features should be added for further protection that will be outlined in the best practices section later in the guide.

Learn more about securing REST APIs here.

How do you secure a GraphQL API?

Next, we will look at securing one of the most recent API technologies, GraphQL. As the adoption of GraphQL grows, GraphQL APIs present a unique set of security challenges. Due to GraphQL’s query language and other features that make it more flexible than traditional API technologies, a new approach must be taken to secure the data within them. Unlike REST, which uses defined endpoints with defined requests and responses, GraphQL allows clients to query for exactly what they need, no more and no less. The dynamic nature of a GraphQL query or mutation can lead to some distinct security considerations.

Authorization and Authentication in GraphQL APIs

First, much like what we discussed regarding securing REST API endpoints, ensuring that Authorization and Authentication are in place is crucial to safeguarding resources. Unlike REST, this becomes relatively complex with GraphQL. Ensuring the user is authenticated to use the GraphQL API can follow a similar pattern to REST, using many of the same mechanisms and technologies.

The complexity comes with the authorization piece, where you may need the ability to control read and write access to certain fields within the GraphQL API. Some API gateway can help with this, as well as the GraphQL framework or platform you use to build the APIs.

Input Validation in GraphQL

Secondly, like REST, securing a GraphQL API requires developers to validate and sanitize all input to prevent malicious activity, such as injection attacks. With GraphQL, this is once again slightly more complex than other API technologies since queries and mutations can be complex and require validation and sanitization to be done at a granular and modular level.

Managing Query Complexity

Another important aspect of securing a GraphQL API is managing query complexity to prevent resource exhaustion, resulting in a denial of service attack. For instance, a common way that GraphQL resources can be exploited is through batching attacks or deeply nested queries. You can mitigate such risks by putting a mechanism in place to limit the depth and breadth of queries, possibly through depth limiting or pagination. As of late, some API gateways that support GraphQL can add these checks and enforce them at a policy level.

GraphQL Introspection

One last consideration that is unique to GraphQL is to consider the implications of introspection. As users of GraphQL know, introspection is a feature in GraphQL that allows the querying of the schema through an introspection endpoint. While this is useful for developers who want to use the service, in production, it might give attackers insights into your API that could be exploited. In the case where the introspection endpoint can’t be disabled, you should think about severely restricting the amount of data that is exposed through the introspection endpoint.

By putting the above security measures and considerations into practice with your GraphQL development, you’ll have the base of a secure GraphQL API. It’s important, though, to remember that these strategies are part of a larger security posture, which we will look at further in the API Security Best Practices section later in the guide.

How do you secure a gRPC endpoint?

The last type of API we will look at will be gRPC. gRPC, a high-performance RPC (remote procedure call) framework created by Google, relies on HTTP/2 for transport and Protocol Buffers as its interface description language. To secure gRPC APIs, you must address the protocol and the message formats.

Input Validation in gRPC Endpoints

Additionally, you’ll also want to make sure always to validate and sanitize all incoming data to prevent injection attacks. With gRPC's strict schema definitions, you can enforce message validation based on the defined Protocol Buffers. This can help detect abnormal messages that could be part of a potential attack, allowing you to add a mechanism to stop such malicious traffic or activity from becoming catastrophic to the system or data within it.

Comprehensive Access Controls

Lastly, you’ll want to implement fine-grained access control for the service. This is particularly important with gRPC due to its ability to create complex service-to-service interaction patterns. If such interactions go unchecked, attacks may be able to penetrate deep into the systems that are exposed through the gRPC calls. By implementing a robust access control strategy, you can ensure that services only have the permissions necessary to perform their intended functions.

What are the principles of API Security?

When it comes to best practices, they are usually driven by underlying principles that help to inform them. Like other best practices, API security is underpinned by principles that guide the development and implementation of secure APIs. Drawing from the OWASP Top 10 for API Security, these principles can be summarized into key areas of focus, many of which we already touched on above. Let’s briefly look at these key areas, listed below, before diving into the best practices section of the guide.

Authorization and Access Control

Effective access control is crucial for securing APIs. It’s not enough to authenticate users; systems must also have proper access controls to check that each user has the right to access or modify their requested resources. This involves implementing checks at both the object level (ensuring users can access only the objects they are permitted to) and function level (actions they can perform). For instance, OWASP highlights broken object-level authorization as a common issue, where APIs expose endpoints handling object identifiers, creating a broad attack surface for unauthorized access.

Authentication Integrity

Authentication is the first line of defense regarding common API security risks. A robust authentication process ensures that only legitimate users can access the API. OWASP notes that broken authentication is a common risk, where attackers compromise authentication tokens or exploit flaws to assume other users' identities. Solutions like multi-factor authentication, token blacklisting, and the use of short-lived access tokens can help to mitigate this risk significantly.

Data Exposure and Validation

With data being collected continuously, private and sensitive data is abundant within the API landscape. Excessive data exposure occurs when an API sends more data than necessary to the client. To combat this, data should be carefully validated on both input and output to protect the system from malicious data and to ensure sensitive information isn’t exposed to the client.

OWASP combines this principle with mass assignment vulnerabilities, where attackers exploit overly wide permissions to modify data they shouldn’t have access to. A mechanism such as an allowlist for data processing and output can help prevent such exposures.

Resource Management

Slightly different from our other principles, this principle is more rooted at the infrastructure level. Here, we are focused on conserving and allocating server resources to prevent service outages or degraded performance. This could be due to a malicious attack or an unintentional issue with how the client uses the API.

OWASP identifies unrestricted resource consumption as a potential risk, which can lead to denial of service or increased operational costs. By implementing rate limiting, quotas, and other controls, you can manage the load on the API and its underlying services to ensure that everything stays within the anticipated ranges.

Configuration Management

Another factor affecting infrastructure is proper configuration management. By following the proper protocols and best practices for configuration, you can ensure that security controls and settings are defined, implemented, and maintained as intended. Misconfigurations can lead to security gaps and are often cited by OWASP as a prevalent risk within the API ecosystem.

Regularly reviewing and updating configuration settings, automating configurations through Infrastructure as Code (IaC) practices, and employing configuration management tools can help maintain a strong security posture throughout all your environments and applications.

Secure Dependencies

Our last principle revolves around the code that our APIs and applications rely on. Dependencies, such as third-party libraries and APIs, can introduce vulnerabilities we may not be aware of. OWASP cautions against the unsafe consumption of APIs and dependencies, where developers may inadvertently trust these third-party resources without proper security consideration. Conducting regular security reviews of third-party services, using Software Composition Analysis (SCA) tools to detect vulnerable components, and applying security patches promptly are key strategies for securely using dependencies.

The principles above form the bedrock of secure API design and operation. By adhering to these principles, organizations can create secure APIs that meet functional requirements. Successful organizations must resist the advanced threats that target today's digital infrastructure, especially when it comes to their APIs.

API Security Best Practices

Now that we have covered all of the basics, it’s time to put these concepts into practice by looking at API security best practices. In this list, we will comprehensively go over different tools and strategies you can use to make sure your APIs are as secure as possible. Let’s dive into the API security best practices you should be applying to your APIs.

Conduct Regular Security Audits and Penetration Testing

First, security audits and penetration testing are needed to test your API’s security protocols. These testing methods are designed to uncover and address vulnerabilities early in development. Regular security audits involve comprehensively examining your API's infrastructure, policies, and codebase to ensure compliance with security standards. Penetration testing, on the other hand, involves simulating cyberattacks to test the resilience of your API against real-world threats.

To implement this, you should schedule regular audits within your development cycle and after any major changes to your API. By using a tool like StackHawk, you can automate vulnerability testing, while hiring external penetration testing teams can provide an outsider's perspective on your API's security. Regular testing helps identify authentication, authorization, and processing logic weaknesses that attackers could exploit.

Implement Strong Authentication and Authorization Checks

Next in importance is authentication and authorization. These mechanisms form the gateway through which access to your API is regulated. As we covered earlier, authentication verifies the identity of users, while authorization determines what they should have access to. A weakness in these areas can lead to unauthorized access and potentially full system compromise.

To implement authentication and authorization, adopt protocols like OAuth 2.0 and OpenID Connect to manage user authentication securely. For authorization, define clear access control policies using role-based access control (RBAC) or account-based access control (ABAC), ensuring that users can only interact with API resources appropriate to their role. Implementing multi-factor authentication (MFA) can add another layer of security, significantly reducing the chance of unauthorized access.

Encrypt Data in Transit and at Rest

Encryption is a necessary practice when it comes to data and information being sent and received by APIs. Encryption converts data into an unreadable format without a key, which is crucial for protecting sensitive information from eavesdroppers. Data in transit refers to data moving across the network, while data at rest is stored on a disk. Both of these states apply to data being transmitted through APIs.

When implementing this best practice, to ensure data is encrypted in transit, use TLS with strong cipher suites. Tools like Let’s Encrypt provide free TLS certificates, helping to streamline this process. For data at rest, apply encryption algorithms like AES and manage the encryption keys securely using managed key services provided by cloud providers or even hardware security modules (HSMs).

Effective Error Handling and Logging

Effective error handling at the code level helps ensure that API errors do not leak sensitive data, while logging records an audit trail of events for later review or real-time analysis. Poor error handling can give attackers clues about the API's internal workings, aiding them in crafting more effective attacks. If attackers can gain access to logs, they could also gain access to private data being logged.

You’ll need to develop a strategy for uniform error responses that conceal implementation details to implement this. Use logging to track and record API transactions, which can help in post-incident analysis and detect patterns indicative of abuse.

Ensure any sensitive details are masked or not included in the log output when logging. Tools like ELK Stack or Splunk can aggregate logs for analysis, and cloud services often offer integrated logging solutions.

Use Throttling and Rate Limiting

Throttling and rate limiting control the number of API requests a user can make in a given timeframe. Throttling controls the amount of throughput, queuing API traffic from calls that have exceeded the throttle limit so they can still be processed in a controlled, non-spiking manner. Rate limiting is a hard limit that will cut off the API request and return an error response to the API caller. Both of these mechanisms help to prevent service overuse and protect against denial-of-service attacks.

The easiest way to implement throttling and rate limiting is by using API gateways or middleware to manage these rules and policies. When configuring rate limiting and throttling, set sensible defaults based on user behavior and scale them according to your service capacity. These settings can often be adjusted in real-time to respond to observed usage patterns or attacks. Examples of gateways that make this easy include Kong, Tyk, and AWS API Gateway.

Ensure Proper API Versioning and Deprecation Strategies

As time passes, you’ll likely continue improving your API from a performance, functionality, and security perspective. You’ll want to make it easy for your API consumers to understand what version of your API they are using, especially if you’ve improved security on the API endpoint. Versioning allows you to make changes and improvements to your API without disrupting existing clients, while a deprecation strategy provides a planned transition for users from old to new versions.

To implement this, you should adopt a clear versioning strategy, like Semantic Versioning (SemVer), which uses a three-part version number: major, minor, and patch. Once a new version of the API is released, communicate changes through a changelog. If you plan to deprecate older APIs, provide ample warning before deprecating old versions and a path for users to migrate to newer versions. Using tools such as API management platforms can help facilitate the control of different API versions and the smooth transition between them.

Embrace a Zero-Trust Network Model

Another best practice to adopt across all the applications and services you provide, including your APIs, is a zero-trust network model. A zero-trust model operates on the principle that no user or system should be trusted by default, even inside the network perimeter. This is particularly important in modern environments where perimeter defenses alone are insufficient. It gives additional security to services when a perimeter defense has been compromised, limiting the impact of intrusions.

To implement zero-trust, there are a few pieces to put in place. First, enforce strict user verification at every level to ensure users are authenticated and authorized. Next, use the principle of least privilege (PoLP) to ensure that a user or entity only has access to the specific data, resources, and applications needed to complete a specified task. Lastly, apply micro-segmentation to logically divide the data center into distinct security segments, limiting lateral movement. With these pieces in place, you’ll also want to use continuous monitoring and validation at every stage of an API call to ensure that the request is legitimate and that the user still has the right to make that request.

Automate Scanning and Testing for Vulnerabilities

At StackHawk, this best practice hits home the most. Automated and scheduled scanning and testing for vulnerabilities helps to identify potential security issues before attackers can exploit them. By making testing part of the development lifecycle, automation can be put in place to test new pieces of code while it is running, in the case of dynamic application security testing (DAST), or by statically scanning the code, like what you would see with static application security testing (SAST). This proactive measure is essential in maintaining the security posture of your API.

In practice, you’ll want to integrate vulnerability scanning and testing into your CI/CD pipeline using automated tools to analyze your code for known vulnerabilities. Enabling scans and tests to execute on every pull request would be the most comprehensive strategy to find issues early. Use various tools and methods such as DAST and SAST tools to test code for vulnerabilities at runtime, check for outdated libraries or dependencies that may contain unpatched security issues, and other security issues. Regular testing should be part of a broader strategy, including staying informed about new security threats and updating your systems accordingly.

Secure the Underlying Infrastructure

Lastly, ensure that the infrastructure your services are deployed on and rely on is secure. Securing the underlying infrastructure involves safeguarding the physical and virtual environments that host your API. Weaknesses in your security framework here can lead to compromised services, data, and access protected resources API, undermining all higher-level security measures. Locking down and securing the infrastructure involves server security, network configurations, and cloud environment configurations.

To fortify your infrastructure, ensure that your team has a strict practice of applying regular updates and patches to your servers, enforcing strict firewall rules, and utilizing some intrusion detection systems. In cloud environments, take advantage of native security features and follow the principle of least privilege when setting up access and provisioning user accounts. Also, regularly review your infrastructure for vulnerabilities and consider employing Infrastructure as Code (IaC) for consistent and repeatable deployments, especially when moving from lower to higher environments. Securing each layer of the infrastructure stack creates a strong foundation for building and deploying secure APIs that your users can trust.

We have covered the most critical best practices for securing APIs. Keeping the above in mind, creating a checklist to implement each best practice correctly would be a great place to start. Of course, there may be other factors to consider depending on the types of APIs you have deployed, regulatory requirements, and other factors that make every security framework unique.

Augmenting API Security With StackHawk

Automated Security Risk Tests

Integration with CI/CD Pipelines

Modern Tooling for Various API Types

Unlike some other tools, StackHawk can support various API types for testing. The tool caters to modern application architectures by supporting REST, GraphQL, SOAP, and gRPC APIs. This helps to ensure that your entire API portfolio has blanket coverage instead of excluding API types that other tools may not support.

Efficient Vulnerability Management

The most powerful outcome for developers that use StackHawk is fast detection and detailed documentation for remediation. StackHawk streamlines the process of fixing vulnerabilities and makes developers' lives easier and the APIs they create more secure. By making the tool developer-friendly, vulnerability management becomes easy to implement and easy for developers to utilize.

Conclusion

As we conclude our in-depth exploration of API security, it's clear that protecting our APIs is critical and complex. Throughout this guide, we've navigated the intricacies of API security, from the foundational principles drawn from the OWASP API Top 10 to the nuanced specifics of securing REST, GraphQL, and gRPC APIs. We capped things off with a look at the strategic best practices that can help fortify your digital defenses and reflected on the importance of each in the broader context of API security.

In the quest for security excellence, tools like StackHawk are indispensable. StackHawk empowers teams to augment their own API security management strategies effectively. With its automated security testing tailored for modern APIs, integration into CI/CD pipelines for early vulnerability detection, and support for a vast array of API architectures, StackHawk ensures that your security testing evolves with your APIs.

Seamlessly Triaging HawkScan Findings from Security in Jira

Omar Alkhalili

When integrating security practices into your team’s software development lifecycle, it can be challenging to manage the vulnerabilities discovered by various security tools and to stay on top of their remediation statuses. With the release of Atlassian’s Security in Jira, Jira Software users can easily manage the vulnerabilities found across their security tools in a consolidated dashboard. As one of the early security vendors selected to partner with Atlassian on this product, StackHawk has built an integration which sends scan findings to be tracked in Jira. StackHawk’s integration can be installed in Jira Software sites and is available in the Atlassian Marketplace. The latest releases from the teams at StackHawk and Atlassian enables users to triage and assign StackHawk scan result findings through issue creation in Jira. Once HawkScan findings are transmitted to Jira projects with the security feature enabled, these findings can be converted into Jira issues. Issues created for vulnerabilities in the security feature will now automatically link back to findings in the StackHawk platform.

Linking Jira Issues with HawkScan Findings

In order to take advantage of this new functionality, it is necessary to install the StackHawk app in your Jira Software site and to enable the Security in Jira integration in StackHawk. It is also necessary to upgrade to the latest version (0.3.0) of the integration in order to use the issue-linking functionality. For more information on this, see the documentation on how to install, configure and upgrade the integration.

Once the integration has been configured and scan findings are being received in Jira, click the “Create issue” button next to a vulnerability in order to create a Jira issue. This will bring up a modal that allows for creating a Jira issue. Once the fields in the modal are filled out and the issue is created, the vulnerability will display the Jira issue key in the Issues column.

Once this Jira issue is created, a corresponding connection will be created on the StackHawk side. Navigate to the scan findings for the most recent scan of the application and environment associated with this vulnerability. In the finding details for the vulnerability, the finding paths will show the same issue key linked from the security feature in Jira. When clicked, the arrow next to the issue key will take you directly to the issue in Jira.

Once Jira issues have been linked to finding paths, the triage status of those paths will be impacted. Those paths will move from the untriaged status of “New” to a triaged status of “Assigned,” meaning that this vulnerability has been converted into an issue or bug in Jira and is ready to be picked up by the development team. The main benefit of this functionality is that it is no longer necessary to do any duplicate work in order to track the remediation status of vulnerabilities in both StackHawk and Jira. The remediation status of vulnerabilities is automatically tracked in both platforms by creating Jira issues. StackHawk users now have the ability to use Security in Jira in order to triage vulnerabilities through issue creation rather than having to perform triage solely on the StackHawk side. Ready for more?

Legacy DAST is Dead! Long Live Modern DAST!

Scott Gerlach

It’s not uncommon for me to hear the following: “DAST is Dead'' or “We can’t use DAST because we only have APIs.” As a co-founder and Chief Security Officer for a company that is 100% focused on the business benefits of DAST, I thought it was time for me to pen my thoughts and share how Dynamic Application or as I like to refer to it lately Dynamic API Security Testing (DAST) is evolving.

Downfalls of Legacy DAST

Legacy DAST has been a longstanding solution for organizations. However, as the use of APIs for application development has surged and security concerns regarding APIs have intensified, traditional DAST solutions have struggled to keep up with these developments.

1. Slow Scans

Traditional DAST scans are notorious for their sluggishness. Part of this is caused by the first issue (testing in production) and the need for rate-limiting, but a ton of this is due to how applications are built. Decoupling the data layer and presentation layer led us to deploy Single Page Applications (SPA). DAST is terrible at SPA due to the inherent nature of how browsers are interpreting javascript code and rewriting the Document Object Model (DOM) on the fly. All of this causes assessments to stretch over hours or even days, which lacks the efficiency needed to complement the speed of development cycles of modern applications. Developers and DevOps teams require faster feedback loops to promptly identify and fix security issues.

2. Lack of API-Specific Capability

Legacy DAST tools were primarily designed to test Web 1.0 applications. This approach worked well in the past but falls short in today’s API-driven world. These tools struggle to comprehensively test APIs, which often form the most exposed and critical part of modern applications. This leaves organizations with unaddressed security vulnerabilities in their API layers.

3. Testing ONLY in Production

Legacy DAST tools often compel organizations to perform security testing in live production environments. While this may yield valuable insights, it carries the inherent risk of disruptions and potential data breaches. The price of compromising the integrity and availability of live applications can be steep, including damage to an organization’s reputation and loss of customer trust. This often leads to scans being surface level and ineffective at testing for real vulnerabilities.

Benefits of Dynamic API Security Testing (DAST)

1. Fast Testing Times

One of the standout features of Dynamic API Security Testing is its remarkable speed. These tools provide orders of magnitude faster feedback, empowering developers and DevOps teams to swiftly identify and address security issues during the development phase. This rapid turnaround time ensures that vulnerabilities are identified and resolved well before they reach production.

2. API-Centric Expertise

Unlike their predecessors, modern DAST tools are purpose-built to address the unique challenges of API security. They possess an in-depth understanding of API-specific attack vectors, authentication mechanisms, and authorization workflows. This specialized knowledge equips them to excel in securing the modern API-driven landscape.

3. Logic Testing

Modern DAST tools are excellent at testing for logic based flaws in APIs. The OWASP API Top Ten includes no less than 4 “improper authorization” issues that you can’t test for with SAST. The primary capability of DAST is to send various iterations of data to an input and check its outputs for responses that might indicate a vulnerability. This type of testing helps to prioritize what issues are the most important to fix by behaving like a user or a threat actor.

4. Testing Before Production

Dynamic API Security Testing aligns seamlessly with the best practice of testing security early in the development lifecycle. By catching vulnerabilities before they make their way into production, organizations can avoid the costly post-release fixes and mitigate security risks more effectively.

5. Automation

Modern DAST tools are synonymous with automation. They intelligently discover, scan, and assess APIs and web applications with minimal manual intervention. This automation streamlines the testing process, reduces human error, and accelerates the security assessment workflow.

6. Closer to the Code

Incorporating closer proximity to the code accelerates the detection of API and application security flaws. A notable advantage of Dynamic API Security Testing lies in its exceptional speed, offering nearly instant feedback. This empowers developers and DevOps teams to promptly pinpoint and rectify security issues in the development stage. Such swift response times guarantee the resolution of vulnerabilities long before they can impact production.

7. Developer-Friendly

Modern DAST tools prioritize developer-first, promoting quicker feedback loops. They integrate seamlessly with development and CI/CD pipelines, enabling developers to incorporate security testing into their workflow. This close collaboration between developers and security teams results in more secure APIs developed faster.

Conclusion

The rate of API-based developed applications is not slowing down. For organizations looking to scale and safeguard their applications and data more effectively, adopting a modern approach to DAST, Dynamic API Security Testing is a necessity. To learn more about StackHawk, sign up for a free account or schedule time to chat with our team of API security experts.

Scott Gerlach is Co-Founder & CSO at StackHawk

5 Best API Security Solutions of 2023

Alexa Sevilla

It’s no surprise to developers and their enterprises that APIs have emerged as the fundamental building block of modern applications and integration. With this massive adoption of APIs across the software development landscape, APIs have become a primary target for cyber threats and attacks. The result is that API security is no longer a mere necessity—it's one of the core factors in the security of overall business operations.

API security is a broad term that encompasses the strategies, technologies, and practices that are used to keep APIs secure and compliant. The significance of adopting a strong API security posture is its capacity to prevent data breaches, safeguard sensitive data, and maintain service integrity. Without success in these areas, an organization's survival and trustworthiness in the modern marketplace would be questioned.

In this blog, we'll explore multiple angles regarding API security, illustrating its importance and inherent complexities. We'll outline what an API security solution typically includes, provide insights on choosing the right one for your organization, and discuss the different types of API security measures that are critical for protecting your APIs. Lastly, we will look at the top 5 API security solutions of 2023. Let’s get started by looking at the basics of API security.

What is API Security?

APIs are the cornerstone of modern application architectures. APIs, or Application Programming Interfaces, have been around since the early days of computing. However, it was the advent of the internet and cloud computing that they really began to take off in numbers and popularity. APIs facilitate the interaction between different software applications, giving a mechanism for applications to communicate, share data, and leverage various services.

Historically, as enterprises began to expose their services over the web, they did so via APIs. This led to a massive increase in the amounts of APIs available as companies worked to make services more widely available internally and externally. Then, with the proliferation of mobile apps, cloud services, and IoT devices, APIs have further expanded their footprint. With each of these expansions in API availability came an increased risk of exposure to malicious activities.

To combat these potential security issues, API security began as a set of best practices. At the most basic level, this included practices such as adding basic authentication and authorization techniques. However, as the threats grew more sophisticated, so did the best practices. Eventually, the need for comprehensive API security solutions became evident to support these standards.

API security, at its core, is about ensuring that interactions with APIs are secure, authenticated, and performed as intended. At a basic level, API security involves several components:

Authentication ensures that the entity requesting access to the API is who it claims to be.
Authorization dictates what an authenticated entity is allowed to do.
Encryption protects data in transit from eavesdropping or tampering.
Input Validation ensures that the API can reject improperly formatted data, which could otherwise lead to SQL injection or other attacks stemming from input.
Rate Limiting prevents abuse of APIs by limiting how many requests an entity can make in a given timeframe.

Within API security, it's clear that threats continue to evolve and require constant attention to stay on top of. Modern API security solutions must anticipate and defend against various attacks outlined in the OWASP API Security Top 10, including

Man-in-the-Middle (MitM) Attacks, where an attacker intercepts communications between the client and the API to eavesdrop or alter the data.
Injection Attacks, such as SQL injection, where an attacker sends malicious input to the API, tricking it into executing unintended commands.
Broken Authentication and Session Management, where poor handling of user sessions and credentials can lead to unauthorized access.
Insecure Direct Object References (IDOR), allowing an attacker to access objects, such as files or databases, directly through the API.
Security Misconfiguration, which can occur at any level of the API stack, from the network services to the application layer, exposing vulnerabilities.

With the basics of API security outlined and some potential attacks that could be executed covered, it’s time to dig deeper into the solutions to combat API-based attacks. Next, let’s take a look at the various API security solutions that are available.

What is an API Security Solution?

API security solutions are a comprehensive set of security measures specifically designed to protect the integrity, availability, and confidentiality of APIs. Some solutions cover various aspects, while others are more honed to cover a single aspect extremely well. The core functions of an API security solution typically align with one or more key areas of API security. Let’s take a look at a few types of API security solutions.

Dynamic Security Scanning and Testing

Modern tools like StackHawk provide dynamic application security testing (DAST) capabilities. These tools allow developers to actively test and find security vulnerabilities within their APIs during the development cycle. This is crucial for ensuring that any security issues can be addressed before the API is deployed into a production environment.

Protection Against DDoS and Automated Threats

Solutions like Akamai utilize extensive networks and advanced algorithms to protect against Distributed Denial of Service (DDoS) attacks and automated threats. This type of tool is required to ensure that APIs remain available and responsive even under attack.

Vulnerability Management for Open-Source Libraries

Given the reliance on open-source software in API development, tools like Snyk can scan for vulnerabilities within these libraries, on top of other functionalities. The platforms detect vulnerabilities and then provide insights and patches to fix them, securing the foundation on which the APIs are built.

Holistic API Protection Platforms

Some platforms aim to offer protection from multiple angles. For example, Noname Security represents a class of solutions that offer holistic protection. These platforms perform real-time traffic analysis, detect and prevent API abuses, and ensure compliance with security policies and regulations.

AI-Driven Security Measures

SALT Security uses artificial intelligence to learn from API traffic and interactions continuously. This allows the tool to identify and mitigate potential threats, including zero-day vulnerabilities that traditional security measures might overlook.

Of course, these are just a few categories within the API security solution category. As we discuss the top 5 API security solutions, remember that each brings unique strengths and often serves complementary roles within a comprehensive API security strategy. Most companies will use a mix of these tools to create their API security stack.

How to Choose an API Security Solution

Choosing the right API security solutions to implement is a pivotal decision that requires a strategic approach. Given the vast amount of options available, it's crucial to select tools that not only address current security needs but are also adaptable to handle future challenges and vulnerabilities. Let’s now take a look at some considerations when it comes to choosing the right tools for your use case.

Assess Your API Landscape

First, you should start by understanding your API footprint. Based on the technologies you are using, such as REST, GraphQL, or gRPC, this will help to determine which tools you can use. For instance, a tool like StackHawk is flexible enough to provide testing coverage for multiple types of APIs. Knowing what technologies are being used within your APIs is a crucial first step to determining the applicable tools.

Identify Your Security Requirements

Next, you’ll need to determine the specific security needs of your APIs. This will depend on factors such as whether the APIs are internal or external and the language/framework the APIs are built with. Specific languages may have inherent vulnerabilities that might be more easily detected and remedied by specific tools.

Integration with Existing Systems

Optimally, The API security tool should integrate seamlessly with your current infrastructure. If you're using CI/CD pipelines for development, you’ll want to find tools that can be configured to run automatically within such an environment. Aim for a tool that does not require infrastructure or process changes to accommodate it.

Regulatory Compliance

Depending on whether your business must comply with any regulatory standards; you’ll want to ensure that the tool helps you comply with relevant regulations. If you’re using a SaaS tool, you’ll also want to ensure the platform complies with your standards (such as SOC II compliance). For instance, if you're dealing with healthcare data, HIPAA compliance would be a priority. For this, you’d want to find a tool that can assist with data protection and access controls.

Performance and Scalability

You’ll also need to keep performance and scalability in check. Tools that take a more active role in security, such as real-time monitoring, should not impede API performance or the API's ability to scale. Look for a tool with scalability that can adapt as your API traffic grows.

Ease of Use and Management

For the sake of the developers and teams using the tool, the solution should be user-friendly. This includes ensuring the tool does not require extensive training to configure, use, and manage. Tools that offer intuitive dashboards and alerts can simplify the task of monitoring API security.

Vendor Reputation and Support

With the vast array of tools available, it also makes sense to research the vendor's track record. Look for user testimonials, case studies, or reviews that indicate the reliability and effectiveness of their solution. Preferably, look for info that reflects your use case, paying attention to any issues that are called out. You’ll also want to evaluate the support services they offer, including if good or bad remarks about it are mentioned in a review or testimonial.

Cost Considerations

Lastly, and sometimes most importantly, consider the cost of ownership for the tool. Some tools might offer basic protection at a lower cost, but you may need more advanced features as your API landscape matures. You’ll want to ensure that the tool brings a sufficient return on investment, balancing the cost of the tool against the benefits it provides.

By carefully evaluating these factors, developers and organizations can make an informed decision on whether the tools they plan to use will work. Making sure that tools align with their security posture, regulatory needs, and operational requirements helps to ensure the chosen API security solution is a good fit for their environment and use case.

What are the Types of API Security?

Before we get into the tools, we should take a deeper look at the different types of API security. API security is a comprehensive term that includes various practices and mechanisms to protect the integrity, confidentiality, and reliability of APIs. Below are some of the critical types of security that should be applied to APIs.

Authentication

Authentication verifies the identity of a user or service requesting access to an API. It's the first line of defense, determining whether a user is who they claim to be. Having an authentication mechanism in place prevents unauthorized access, ensuring that only validated users can interact with your API endpoints.

Authorization

Once a user is authenticated, authorization determines what they can do and what endpoints they can access. It's about granting appropriate access levels and permissions to authenticated users. Effective authorization ensures users can only perform actions that align with their permissions, which is crucial for maintaining data integrity and privacy.

Encryption

Encryption secures data in transit and at rest, making it unreadable in its encrypted state. This helps to protect sensitive information from interceptors. Encryption while data is in transit and at rest is vital for protecting data confidentiality and preventing breaches. Most API consumers will want to know what encryption mechanisms are in place since it is critical for user trust and legal compliance.

Rate Limiting and Quotas

Rate limiting and quotas control the number of API requests a user can make in a given period. This helps to manage API traffic and helps to prevent abuse, which may be intentional, such as a Denial of Service attack, or unintentional, such as an unintentional recursive API call in the code. Rate limiting is a frontline measure for preventing service outages caused by intentional attacks or unintentional traffic surges.

Input Validation

Input validation checks user input against a set of rules before processing, ensuring only expected and adequately formatted data is accepted. Input validation is crucial for preventing many different types of attacks, such as SQL injection, that exploit input vulnerabilities. Many languages and frameworks have best practices, sometimes baked in, to ensure that input validation and sanitization are handled correctly.

Security Misconfiguration Protection

This type of security addresses vulnerabilities that arise from insecure default configurations or incomplete setups. This could happen at the infrastructure layer or even in the code. Addressing security misconfigurations closes gaps that attackers often exploit, which can prevent data leaks and unauthorized access.

Automated Threat Detection and Response

This involves real-time monitoring of API traffic to identify and mitigate threats as they occur. API traffic is automatically monitored and assessed, more commonly through AI, to check for potential issues. Quick detection and response limit the damage from any attacks being executed, reducing potential downtime and preserving data integrity.

API Gateway Security

Another type of API security is introducing an API gateway or API management tool. The gateway is an additional layer between an API client and your APIs, enforcing security policies. API gateways centralize security management, reduce complexity, and offer an additional layer of defense. Popular API gateways include Kong, AWS API Gateway, and Tyk.

Automated Security Scanning and Testing

With automated scanning and API security testing, your code and running application can be scanned for potential vulnerabilities that stem from any of the above factors. For instance, a static code analysis tool, such as Snyk, can help to look directly at the code to see if any vulnerabilities are present. With a dynamic application security testing tool like StackHawk, the running application can be tested for vulnerabilities that can actually be exploited. Using automated testing like this can help uncover issues with authentication, authorization, injection/input validation issues, etc.

Each type of API security plays a role in a layered defense strategy, ensuring comprehensive protection. Implementing a combination of these types creates a robust security framework that can adapt to emerging threats and protect an organization's data and APIs.

The 5 Best API Security Solutions of 2023

Now that we have covered the various API security solutions, it’s time to look at five of the best and most popular available tools. In the rapidly evolving landscape of API security, several solutions stand out for their innovative approach to API security. Let's look below at the top five API security tools of 2023.

StackHawk

The first tool we will look at is Stackhawk, a dynamic application security testing (DAST) solution that empowers developers to find and fix security vulnerabilities. StackHawk enables users to test their APIs and web applications automatically right from the beginning of the development process. For example, a company can integrate StackHawk into its CI/CD pipeline to automatically test APIs after each deployment. This ensures that vulnerabilities in the running application are caught and remedied before they reach production.

Benefits of StackHawk

Seamlessly integrates with modern development workflows, including directly in CI/CD.
Enables early detection of security issues in running applications.
Enhances developer productivity by automating security testing and reducing “false positive” detection.
Provides clear vulnerability documentation to help developers quickly fix issues.

Akamai

Akamai is a comprehensive, cloud-based security platform known for its cloud security solutions. Akamai’s CDN technologies protect extensively against large-scale DDoS attacks and automated web attacks. For example, an e-commerce platform can leverage Akamai's CDN to protect its APIs from DDoS attacks during high-traffic events, such as those that might occur during Black Friday sales.

Benefits of Akamai

Extensive network capable of absorbing large DDoS attacks.
Advanced threat intelligence to proactively counteract emerging threats.
Optimizes API performance with its CDN capabilities.
Provides automated web attack protection and malicious bot management.

Snyk

Snyk specializes in scanning, prioritizing, and fixing security vulnerabilities within code, open-source dependencies, container images, and infrastructure as code configurations. For example, a fintech startup could use Snyk to continuously scan API code and dependencies its APIs for vulnerabilities in open-source libraries, keeping its financial services secure.

Benefits of Snyk

Includes a comprehensive database of known vulnerabilities.
Can be integrated directly into the development process, including in CI/CD flows.
Offers real-time alerts and automated fixes for vulnerabilities.
Supports a wide range of programming languages and environments.

Learn how StackHawk and Snyk correlate dynamic and static API Security Testing for faster fixes.

Noname Security

Noname Security offers a holistic API security platform that performs real-time traffic analysis to detect and prevent API abuse. It can also help to ensure compliance with security policies and standards, such as the Payment Card Industry (PCI) standard and the Health Insurance Portability and Accountability Act (HIPAA). For example, a healthcare provider could use Noname Security to monitor API traffic for abnormal patterns indicating a data breach, protecting sensitive patient data.

Benefits of Noname Security

Provides complete visibility into API traffic and security posture.
Detects and mitigates sophisticated API attacks and vulnerabilities.
Helps with regulatory compliance through robust data protection.
Offers a zero-trust architecture for API security.

SALT Security

Our last tool to highlight is SALT Security. SALT Security’s platform employs AI to provide continuous discovery and real-time protection for APIs against attackers. This offers insights into the security of an organization’s APIs throughout their lifecycle. For example, an online retailer could use SALT Security to analyze its API traffic patterns and identify fraudulent transactions before they affect the business.

Benefits of SALT Security

Utilizes AI to identify and respond to anomalous behavior quickly.
Continuous discovery and assessment of API risks.
Provide insights into API usage and potential security gaps.
Helps prevent business logic abuse through sophisticated pattern recognition.

Each of these API security solutions offers unique capabilities to address the diverse needs of modern digital enterprises. By leveraging these tools and potentially layering many of them together, organizations can strengthen their defenses against the sophisticated threat landscape they and their APIs face.

Conclusion

In this review of API security solutions, we've uncovered the importance of safeguarding one of the most critical pieces of modern enterprises: APIs. We explored the essence of API security, looked at the basics of what an API security solution is, and provided a framework for choosing the right tool for your needs. We also broke down the types of API security to give you a clear view of the defenses that should be in place to ensure secure APIs.

Lastly, we introduced the top 5 API security solutions of 2023—StackHawk, Akamai, Snyk, Noname Security, and SALT Security. We looked at each tool's unique benefits, from StackHawk's developer-centric security testing to Akamai's robust DDoS protection, Snyk's vigilant open-source scanning, Noname Security's comprehensive traffic analysis, and SALT Security's AI-driven insights.

If you're ready to take your web application and API security testing to the next level, take the first step by signing up to try StackHawk. With its seamless integration into your development processes and CI/CD pipelines and powerful API security testing capabilities, StackHawk ensures that your APIs are built securely from the start.

Alexa Sevilla is Director of Product Marketing at StackHawk

Top 4 Ways StackHawk Customers Shift Left

Casey Cline

The other day, one of our awesome new StackHawk customers asked, “Hey, do you have a list of the top best practices for new StackHawk customers? We want to make sure we’re getting the most out of this tool.”

What a fantastic idea! Over here on the Customer Success team, we are obsessed with ensuring our customers achieve maximum value for their investment. After all, you purchased StackHawk because you want to shift left, and we’d like to help that happen. So, without further ado, here are our top 4 best practices as you roll out with StackHawk:

Include Devs Early and Often

First, and perhaps most importantly, remember that StackHawk was built with devs in mind. StackHawk was designed to be automated into the CI/CD pipeline, allowing your engineers to find and fix vulnerabilities before deployment. After all, that’s what we mean by shifting left.

Ideally, StackHawk will become a welcome and routine part of the workflow for your developers, helping ease their worries about vulnerabilities long before your apps make their way to a customer.

In order to truly shift left with StackHawk, consider including devs from the beginning. Invite them to demos and POV sessions during the procurement process. Include them on invites for kick-offs and health checks with your Customer Success Manager or technical calls with a Solution Architect. If you have a shared Slack channel with StackHawk, make sure devs are included.

By taking this approach to shifting left, you will help build more buy-in from your Engineering team and improve Security-Engineering alignment.

Triage Initial Findings

One of the many benefits of Dast scanning is that it reduces noise, allowing the engineering team to focus only on new or critical findings. If StackHawk is your first Dast tool, however, you may get a lot of results on that first scan. This can feel like a daunting problem to hand off to an already super busy engineering team.

One best practice we recommend is to do a triage and remediation session for those initial findings. This baselines the application you’re scanning, allowing you to hand off StackHawk to your devs with no tech debt. Go through your initial findings and mark them as “risk accepted” for low-risk vulnerabilities, “false positives” where applicable, or create and assign tickets for remediation.

The result? A beautifully clean slate to hand off to Engineering. Instead of wading through a bunch of old or irrelevant results, your devs can simply focus on any new vulnerabilities that are found.

Don’t Forget to Set Tech Flags

Speaking of false positives, StackHawk customers eager to get the most out of their new tool optimize their set-up to be as tailored as possible. One easy way to do this is to set tech flags.

This simply means unchecking any apps or technologies (like databases and programming languages) you don’t use as an organization, which in turn stops those items from causing false positives. Now, your scans will be set to only focus on the technology you actually use.

Don’t Be Shy About Authentication

While any scanning may be considered better than no scanning, in order to get deeper and more comprehensive scan results, you will have to look at authentication. Chances are that many paths of your applications or APIs are protected by authentication. In order for StackHawk to access those protected paths, you will need to set up authenticated scans within StackHawk.

Luckily, we’ve created tools to help you do just that. The most common approach is to configure the stackhawk.yml file with your application’s authentication flow information.

For a more in-depth look at authenticated scanning, check out this helpful guide.

So there you have it- a few simple ways to make the absolute most of your investment in StackHawk. Hungry for more knowledge? Check out our extensive and easy-to-follow docs library.

Casey Cline is a Senior Customer Success Manager at StackHawk.

gRPC Security: How StackHawk Tests gRPC Services

Austin Pearigen and Dana White

In a time where API security is paramount, the adoption of gRPC (gRPC Remote Procedure Calls) is on the rise, offering advantages like performance gains and language-agnostic interfaces. However, the security aspects of gRPC remain a challenge and a mystery.

In this blog post, StackHawk engineers Dana White and Austin Pearigen break down the challenges of securing gRPC services and provide solutions through the lens of Dynamic Application Security Testing (DAST).

What is DAST?

Dynamic Application Security Testing (DAST) is a technique that mimics a hacker's actions to identify vulnerabilities in a live application. It explores the full surface of your application, checking for issues like SQL injection, among others. At StackHawk, we've developed a tool that enables this kind of testing, allowing engineers to shift security left in the development process.

Challenges in gRPC Security

Authentication

Authentication is always a challenge, especially when it's designed not to be automated. Legacy systems often have complex authentication mechanisms that are poorly documented. To address this, we've built a developer tool, Hawk Perch, that uses gRPC to iterate quickly on authentication configurations. This tool provides real-time feedback, making it easier to test and adjust authentication mechanisms. See how it works below.

[Video]

Scanning gRPC Services

Traditionally, DAST tools have been limited to HTTP/1-based services. However, gRPC runs over HTTP/2, which presents a challenge for traditional scanners. We've extended our tool to support gRPC, allowing us to test these services directly.

How We Scan gRPC Services

File Descriptor Set

To understand a gRPC service, we use a file descriptor set, which can be generated from the service itself or accessed via reflection. This descriptor set provides us with the information we need to understand the service's schema.

Dynamic Messages

We use gRPC's Dynamic Message class to construct messages at runtime. This allows us to generate messages based on the file descriptor set, which we can then send to the gRPC service for testing.

Custom Variable Injection

Our tool supports custom variable injection, allowing you to specify particular values for certain fields. This is useful for testing different logic branches in your code. Below is an example configuration using custom values:

Scanning gRPC Services with StackHawk

In this video, we demonstrate how the StackHawk platform works, showing a scan against a vulnerable gRPC application. The scan identifies various vulnerabilities, including SQL injection. Our platform provides detailed information on each vulnerability, along with remediation steps.

[Video]

FAQs

Does StackHawk scan for vulnerabilities other than SQL injection? Yes, our tool checks for a wide range of vulnerabilities, including all the OWASP Top 10.
Is an agent required? No, as long as we can access the application, we can scan it. We recommend running the scanner as close to the application as possible for latency reasons.
Is it free to get started? Yes, we offer a free trial account where you can scan a single application as much as you want.

Wrapping it up!

Security is a critical aspect of any application, and gRPC services are no exception. With the right tools and practices, you can identify and fix vulnerabilities before they become a problem. At StackHawk, we're committed to making this process as seamless as possible, helping you secure your applications effectively.

Dana White and Austin Pearigen are Software Engineers at StackHawk

Get started today:

StackHawk + GitHub: Dev-First Security Testing Across the GitHub Universe

Nicole Jones

StackHawk and GitHub work together to help developers find and fix security vulnerabilities in their normal workflows and give security teams full visibility into their entire attack surface. The integration combines the power of StackHawk's dynamic application and API security testing capabilities with GitHub's collaborative platform to introduce a modern developer-first approach to security testing.

But what does developer-first security mean?

An application security tool being "developer-first" means that it prioritizes the needs and workflows of developers when it comes to identifying and fixing security issues in software applications. Here are the criteria for a developer-first security tool:

Easy to integrate: A developer-first security tool can seamlessly integrate into the developer's existing workflow and tools, such as CI/CD pipelines and source code managers. It levels up their coding processes without disrupting them.

User-friendly: The tool has to have an intuitive user interface and provide clear, actionable insights into security vulnerabilities. Developers don't want to waste time deciphering complex reports and going down rabbit holes; they want straightforward guidance on how to fix the issue.

Low false positives: Nothing frustrates developers more than dealing with a flood of false positives. A developer-first tool minimizes false alarms, ensuring that developers can easily prioritize and focus on real issues.

Automation: The tool must automate security testing as much as possible and catch vulnerabilities early in the development cycle. Developers run automated unit and integration tests and fix code as they are working on it, not months later once it’s in production.

Customization: Developers have different needs, preferences, and techstacks. A developer-first tool allows customization, so developers can tailor security testing to their specific requirements.

Developer-first security testing with StackHawk and GitHub

StackHawk offers a number of powerful integrations within the GitHub ecosystem, enhancing the developer experience and making security testing seamless. Let's take a closer look at four key integrations:

GitHub Insights

GitHub Insights provides continuous discovery and visibility of your organization's entire attack surface from the inside out.

For security teams, the Repositories page is a goldmine of information. It enables them to continuously monitor and assess the security of API and application assets across the organization. This level of visibility ensures that security measures can be put in place for new assets as they are added, and existing measures can be adjusted as needed— a crucial capability with how quickly new routes and endpoints are deployed today.

How it works

StackHawk pulls metadata from your organization's repositories into the StackHawk platform for security teams to easily track and monitor coverage on a single page.

You can view details such as repo name, the StackHawk Application it’s mapped to, last commit and scan date, and last contributor to help understand the full scope of your organization's attack surface and collaborate with developers more efficiently.

Learn more about GitHub Insights

GitHub Actions

GitHub Actions enables automated security testing in your continuous integration/continuous deployment (CI/CD) pipeline. This feature brings security testing up to speed with software development as it allows you to automatically test your code for security issues at the same time as your regular testing processes like unit and integration testing.

This means every time a developer checks in code, you can automatically test your application and discover any new security issues as soon as they are introduced and fix them before they ever reach production.

How it works

The HawkScan action found in the GitHub Actions Marketplace simplifies embedding StackHawk into GitHub Actions workflows. It’s a comprehensive action that is easy to configure and has the flexibility to handle complex use cases.

The HawkScan Action can run most tests with just a single parameter, your StackHawk API key, and a four-step workflow. For example, to scan a Node.js app, your GitHub Actions workflow would be as simple as this:

Learn more about the HawkScan Action

Pull Request Checks

GitHub Pull Request Checks deliver security feedback to developers on every pull request. By automating testing in a CI/CD pipeline, we are able to provide a few configuration options that allow your pipeline to explain how each scan maps back to your source code’s history. This creates a fast feedback loop for developers by associating scan results with the specific pull request, branch, and commit information. StackHawk then leverages this context to post test results as comments on the pull request.

The ultimate goal is to help developers iterate faster and be confident they are upholding the security requirements of the application.

How it works

When someone submits a pull request, and before it's merged into the main codebase, StackHawk's integration with GitHub automatically checks it for security vulnerabilities. If any issues are identified, rich test details are commented right in the pull request, alongside regular code reviews. This immediate feedback loop allows developers to address security concerns as they come up, rather than dealing with them later in the development cycle. It's a win-win for both developers and security teams, fostering collaboration and proactive security practices.

Learn more about Pull Request Checks

CodeQL

The GitHub CodeQL integration takes operational efficiency to the next level. It correlates dynamic application security testing (DAST) and static application security testing (SAST) vulnerability findings to provide developers with precise information about where an exploitable vulnerability lives in their codebase.

This level of granularity is a game-changer for developers, as it enables them to fix security issues faster and with greater precision. They don’t have to sift through endless lines of code trying to identify the root cause of a vulnerability; they can jump right into recreating and fixing the issue instead.

How it works

Once a StackHawk Application is mapped to a GitHub repository, scan results in StackHawk will display a GitHub badge when findings from both tools are matched based on the CWE ID.

If StackHawk finds an exploitable vulnerability and GitHub identifies that same issue, the vulnerability request and response information from StackHawk is reconciled with the exact line of code causing the issue from GitHub.

Learn more about CodeQL

Give it a try!

StackHawk's deep integrations with GitHub change the way developers interact with security. By embedding security testing seamlessly into their workflows, developers can proactively fix vulnerabilities in the context of their code, significantly reducing the risk of introducing bugs into production and the time it takes to fix them. With GitHub Insights, the HawkScan Action, Pull Request Checks, and CodeQL Integrations, StackHawk empowers developers to build secure code efficiently and effectively.

Sign up for a free trial of StackHawk and look for the HawkScan Action in the GitHub Actions Marketplace or the StackHawk app in the GitHub Applications Marketplace to get started today.

StackHawk + Snyk: From Integrate to Inte-Awesome

StackHawk

StackHawk and Snyk first teamed up to build a best-in-class Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST) integration. This technical integration was born from the idea that enabling engineering teams with the right tooling and processes to work within developer ecosystems helps improve how teams can find and fix security vulnerabilities prior to deploying to production.

More about our best-in-class integration here: https://www.stackhawk.com/snyk/

But it takes more than a technical integration and a streamlined sales process to make a strong, long lasting partnership. So what are the keys to the success that StackHawk and Snyk have found?

It really comes down to two things: Market-Driven Momentum and Developer-First Cultures.

Market-Driven Momentum

Snyk has done an amazing job paving the way for developer-first application security testing with SAST and StackHawk’s DAST is a perfect complement. We make it easy to correlate findings from a Snyk Code test, enabling teams to better prioritize fixes and helping to streamline API and application security testing.

With this joint solution, we’ve seen significant interest and enthusiasm from a variety of customers spanning different industries. Many are looking to shift application security left, while bridging the gap between developers and AppSec teams to drive efficiencies and accelerate go-to-market strategies. Others are looking to displace legacy vendors, which are not typically user (i.e. developer) friendly, have significantly slower scan times, and can’t keep pace with modern software architecture and tools.

StackHawk and Snyk were both created for modern apps and teams with the ability to find and fix security bugs in microservices, any type of API, and modern development languages.

Developer-First Cultures

The other key to our successful partnership is the fact that StackHawk and Snyk share similar cultures and philosophies - with developers and development teams at the center of everything we do.

Developer-first security testing isn’t just a tagline from our website - it’s at the core of everything we do as a company and through our partnership with Snyk. We believe that Developers should be equipped with the information and tools they need to fix vulnerabilities quickly and get back to feature development. And when two companies partner together and truly align on a common mission, it can be really powerful.

The StackHawk and Snyk Difference

Since the launch of our integration, we’ve continued to find new and exciting ways to partner with the Snyk team to better meet the needs of engineering and AppSec teams of every size. We’re thrilled to announce a new stage in our partnership enabling Snyk to sell StackHawk DAST to their customers. “Snyk and StackHawk bring developer-first perspectives to application security through their modern approach to SAST and DAST. Together, we’re able to provide customers with an automated, scalable approach to securing applications in the pipeline, before shipping to production.” said Carey Stanton, SVP, Business Development. “We’re excited to strengthen our partnership with StackHawk, offering a seamless approach to building a strong security posture through application security.”

Allowing customers to purchase StackHawk through Snyk not only simplifies the purchase and procurement process, but also accelerates the time to value for customers looking to purchase a complete set of application security tooling.

For more information about StackHawk and Snyk, visit: https://www.stackhawk.com/snyk/

Announcing GitHub Insights

Nicole Jones

Tired of being the last to know when new code is deployed and routes are added to your attack surface?

Meet GitHub Insights, your one-stop-shop to get a Hawk's eye view of your entire attack surface. With this information, you can identify gaps in coverage, align security testing with software development, plan security measures for new assets early in the development process, and collaborate with engineering more efficiently.

How it Works

StackHawk's GitHub integration pulls metadata from your organization's repositories into the StackHawk platform for security teams to easily track and monitor coverage under one roof in the Repositories page.

The integration uses read-only access to extract helpful metadata from your repositories, such as repo name, size, last commit date, and last contributor. By surfacing meaningful metadata from your repos, you can quickly identify and configure applications for testing, maintain continuous visibility of your organization's attack surface, and collaborate with engineering more efficiently.

GitHub Insights can help you answer questions like:

"What's the state of my organization's onboarding process? Which StackHawk apps are configured, which are still not mapped?"
"Is my security coverage keeping up with the speed of development?"
"Who should I work with from engineering when I need to configure a new application for testing or a vulnerability arises in a scan?"
"What repositories in my organization contain key assets/services that should be under test (i.e. APIs)?"

👀 Watch the recording from our Office Hours session, Gitty Up with GitHub Insights, to see it in action!

The StackHawk + GitHub Difference

Early Discovery from the Inside Out

Most tools focus on discovering application and API assets after deployment to production, creating a wild goose chase for security teams.

GitHub Insights takes a proactive approach by surfacing repo activity to give security a heads-up before assets are in production. With early insight and context, security teams can strategize on coverage instead of constantly playing catch-up with new and existing applications and APIs.

💡Tip: Use the Repositories filter to identify new assets not under test.

Rapid Application Onboarding

GitHub Insights expands our efforts to take the pain out of deployment and configuration so teams can get their first test under their belts in minutes instead of hours or days.

With your attack surface in front of you, you can quickly create multiple applications in StackHawk at once and flow through onboarding with our step-by-step callouts to move you through the process.

💡Tip: Select multiple repositories to create new applications in bulk or map them back to existing StackHawk applications.

Continuous Visibility of Your Entire Attack Surface

Development never stops, and the state of your coverage today may be different a few months down the road as new assets come online.

As a security tool built for teams deploying software daily, we wanted to provide security folks with a line of sight into what’s happening in their organization. GitHub Insights delivers a high-level view of your organization’s attack surface by connecting application and API assets to their origin source— the code. With continuous visibility of repo activity, your team can plan and recalibrate security measures to ensure your state of coverage aligns with the speed of development and product delivery goals.

💡Tip: Compare the Last Scan and Last Commit dates to ensure your testing frequency provides appropriate coverage.

Efficient Collaboration Between Security and Engineering teams

Determining who to partner with from engineering when a new service needs to be configured for testing or a vulnerability arises is tough when developers outnumber security 100:1.

We've found the most efficient place to start is with the last person working on the code. GitHub Insights tells you the last code contributor so you can collaborate with the right person to get the answers and results you need faster.

💡Tip: Invite the Last Contributor to StackHawk to help configure a new application or access vulnerability details and fix guidance.

GitHub Insights is in open beta for all StackHawk customers. If you’re interested in trying it out, sign up for a free trial or reach out to see a demo.

Managing Node and NPM Versions in Our Projects: Best Practices for Developers

Brandon Ward

It sounds ideal to have the same Node and NPM versions for all projects in your shop. However, if you have ever tried to enforce this, even with just a few projects, it tends to fall over quickly. Therefore, rather than trying to solve that holy grail of Node development, let's instead focus on making the tools work for us.

Embracing Node Version Manager (NVM)

Our first step towards version management bliss is to encourage all of our engineers to install Node Version Manager (NVM) on their local machines. NVM allows developers to easily switch between different Node versions and ensures that each project uses the appropriate version required for its specific dependencies.

There are several Node version managers. Here's the reasons we picked NVM (Disclaimer - this is not to say your node version manager does not support these):

Node Version Management Requirements:
- Had to be easy to switch versions. ✅ => nvm use
- Had to be easy to install versions. ✅ => nvm install x.y.z
- Had to be easy to upgrade npm to the latest compatible version for this node version. ✅ => nvm install-latest-npm
- Bonus: Had to be automatic. ✅ => Set and forget, never worry about your node version again.
CI Environment
- Same configuration file can be used to drive Node version on CI => ✅ actions/setup-node@v3 can understand this file.
- Can automatically use newer NPM versions that are compatible. => ❌ but we came up with a workaround!

Bonus: Automatic NVM

We recommend configuring NVM in auto nvm use mode, which detects the appropriate Node.js version for a project based on the .nvmrc file present in the project's root directory as your shell enters this directory. This way, developers don't have to worry about switching Node.js versions manually; NVM handles it seamlessly!

Utilizing the "engines" Block in `package.json`

To further enforce the compatibility of Node and NPM versions within our projects, we've started using the "engines" block in the package.json file. This block allows us to specify the required versions of Node and NPM for the project explicitly.

This is useful to help protect folks from accidentally using incompatible node and npm versions in the project, and is a gentle reminder to either: a) configure nvm in automatic mode. b) run nvm use c) run npm install-latest-npm

To ensure that these specified versions are strictly adhered to, we set engine-strict=true in the .npmrc file of our projects. This flag ensures that NPM will halt the installation if the required versions are not met, preventing potential incompatibility issues.

Here's what our updated .npmrc looks like: registry={our-registry} engine-strict=true

Where We Needed This

This particular solution helped us solve an issue with a project stuck on Node 14. Node 14 ships with npm v6, which uses an older `package-lock.json` strategy. If folks used npm v6 instead of npm v7 (which is supported by Node 14) with the newer `package-lock.json` spec, we would experience `package-lock.json` thrash, where a perpetual tug-of-war between the 2 strategies in source control would unfold. This is not fun, and we would prefer the `package-lock.json` to stay consistent.

Seamless CI Integration with GitHub Actions

One of the key problems we needed to solve was the seamless connection of Development mode with CI mode. These two experiences needed to be closely connected and work toghether instead of being disjointed. Remember the checklist for why we picked NVM? Well, here's why it matters. GitHub Actions can understand .nvmrc for setting up Node. Let's look at our shared Actions configuration:

Since this is a shared Actions configuration, we only want to setup node for builds that need it. By looking for .nvmrc to do this, we enforce projects that need Node to include a .nvmrc - That's a win! Second, by using this file to control CI, we are doing everything we can to make sure development and CI use the same node version for a project.

Handling NPM Versions in CI

While "actions/setup-node" works brilliantly for managing Node.js versions in our CI environment, we encountered a minor challenge when handling NPM versions. As of version 3, actions/setup-node lacks built-in tools to manage the corresponding NPM version for a particular Node version. The project simply recommends you install a newer version of npm if you need it with npm install -g npm@x.y.z. This is... not great... for shared CI configuration. Enter, our workaround!

To address this, we devised a clever solution by introducing the .npm-version file in repositories that require a specific NPM version alongside their Node.js version. Similar to the .nvmrc file, the .npm-version file contains the desired NPM version for the project.

The `.npm-version` file can look as simple as: 8.19.4

This tells our CI pipeline to use npm@8.19.4 as you'll see below. Consider this Actions configuration:

In our CI pipeline, we use the `.npm-version` file's existence to trigger an NPM version upgrade command, ensuring that the required version is installed before executing other build steps. All we do is extract that version from our new file convention, and use it to install the version of NPM we want.

With this approach we achieve a consistent and efficient version management process for both Node and NPM in our CI environment.

Better yet, while it's not perfect, there is documentation as code for the NPM version in CI if it's not the default version shipped with Node.

Conclusion

Managing Node and NPM versions across a multitude of projects can be a daunting task, but with the right tools and practices, it becomes an organized and streamlined process. By leveraging NVM, utilizing the "engines" block, and introducing custom version management files in our CI, we've been able to ensure compatibility and stability across our projects.

We hope that sharing our approach will help fellow developers in their version management journey. Feel free to adopt and adapt these strategies to suit your team's specific needs, and may your projects always run on the right Node and NPM versions!

Brandon Ward is a Sr. Senior Software Engineer at StackHawk

A Birds-Eye View: Demoing StackHawk at BlackHat 2023

Brian Erickson

BlackHat 2023 has come to an end, and it was an exciting experience for the StackHawk team. My colleagues Austin, Zach, and I had the privilege of representing StackHawk at this significant cybersecurity event, where we demoed our platform and connected with professionals who share our passion for Dynamic Application Security Testing (DAST).

StackHawk's participation in BlackHat 2023 was not just about showcasing our dedication to application and API security testing. It was an opportunity to engage with the community, learn from others, and validate our modern approach to DAST.

In this blog post, we'll share some key takeaways from our time at BlackHat. From the features that captured the audience's attention to the conversations that inspired us, we'll provide a succinct summary of what we learned and how it shapes our perspective on security testing.

Stay with us as we dive into our BlackHat 2023 experience and what it means for StackHawk and the industry as a whole.

Understanding DAST and StackHawk

It only took a short lap around the show floor to make it clear the world of security testing is vast and complex. During our time at BlackHat 2023, we were able to shed light on a particular aspect that's close to our hearts at StackHawk: Dynamic Application Security Testing (DAST).

How StackHawk is Modernizing DAST

One fascinating discovery was how many security professionals were not only new to DAST but also surprised that such a developer-friendly tool exists. DAST evaluates running applications for vulnerabilities, providing real-time insights into potential security risks. Unlike traditional methods that only review the code, DAST actively simulates potential attacks, bridging the gap between developers and security experts.

Illustrating where DAST fits into the modern Secure Software Development Life Cycle (SSDLC) became a significant part of our discussions. By showing how StackHawk integrates near unit testing and integration testing, we were able to distinguish our approach from typical dynamic security testing tools. This positioning resonated with security professionals, as it emphasized StackHawk's alignment with modern development practices, reinforcing the principle of 'trust and verify'.

Introducing StackHawk

But what makes StackHawk stand out in the crowded field of security testing? Is it an awesome logo? The coolest t-shirts? You guessed it - we've got those too. However, our platform goes beyond the basics, not only embracing the principles of DAST but also elevating them to new heights.

StackHawk's dedication to application and API security testing is built around making security an intrinsic part of the development process. By offering real-time insights and seamless integration with existing workflows, we empower developers to address security issues early and often. This proactive approach not only detects vulnerabilities but also provides the tools to fix them, enhancing security without sacrificing agility or efficiency.

Our time at BlackHat confirmed that there's a hunger for developer-friendly security tools that integrate smoothly into the modern SDLC. By focusing on DAST and highlighting how StackHawk uniquely addresses this need, we were able to connect with like-minded professionals and reaffirm our commitment to innovating the security landscape.

Highlights of Our Demonstration

BlackHat 2023 was a stage for innovation and connection, and our demonstration of StackHawk's features was met with interest, curiosity, and even surprise. Here's what captured the audience's attention:

What Demoed Well

GitHub Insights Beta: Our newly introduced GitHub Insights Beta attracted interest with its streamlined onboarding process based on git repositories. By showing an inventory of all of a customer's repositories, including scan status and last commit date, we illustrated how StackHawk simplifies and enhances the efficiency of the security workflow. (psst - GitHub Insights Beta signups are open)
Optimization Panel: The Optimization Panel's ability to indicate whether a scan was complete, based on criteria like Authenticated Scanning, API Discovery, and Technology Flags, struck a chord with many. It demonstrated StackHawk's dedication to providing thorough and precise security assessments without unnecessary complexity.
SAST Integrations: Discussing our integrations with Snyk and GitHub CodeQL emphasized StackHawk's adaptability and alignment with tools already popular among developers. This connection not only affirmed our role in the security ecosystem but also demonstrated how we're making security testing more accessible and integrated.
Streaming Security Test Results: Our real-time streaming of results as security tests are running resonated strongly with attendees. This feature showcased how StackHawk provides a transparent and immediate understanding of the application security test findings, bringing otherwise hidden insights to the forefront.

Best Reactions

Austin's Developer Story: Our own Austin brought the process to life by sharing his personal story as a developer. From discovering a security issue to utilizing StackHawk's platform to understand, reproduce, find a fix, and get that fix into production, his story resonated with the everyday challenges and triumphs of the development world.
Attendee Surprise: Perhaps one of the most rewarding moments was a conversation with a conference attendee who didn't even realize a tool like StackHawk existed. Walking away impressed, he captured the essence of what we strive for at StackHawk: building exactly what developers and security professionals need, even when they didn't know they were looking for it.

Our demonstration at BlackHat was not just about showcasing features; it was about sharing our vision and passion for making security an integral and accessible part of the development process. The reactions and connections forged confirmed that StackHawk's approach resonates with those who are on the front lines of building and securing the digital world.

Aligning with the Conference Theme: API Security Testing

A prominent theme at BlackHat 2023 revolved around the crucial role of API Security Testing in today's interconnected digital landscape. As organizations continue to rely on APIs to drive innovation and enable seamless integrations, the importance of discovering and testing all the organization's APIs cannot be overstated.

StackHawk's platform is uniquely positioned to address this growing concern, and our demo at BlackHat showcased precisely how we are making strides in this area. Here's how:

Comprehensive Discovery: Our platform's ability to perform Authenticated Scanning, API Discovery, and Technology Flags ensures that all relevant APIs within an organization are identified and assessed. This breadth of coverage is vital in today's complex and diverse technology environment.
GitHub Insights for Streamlined Workflows: Our new GitHub Insights Beta feature streamlines the onboarding process and offers a concise view of all repositories, enhancing the efficiency of managing and testing APIs across an organization.
Optimization Panel: The Optimization Panel's ability to indicate a complete scan ensures that every aspect of an API is thoroughly evaluated, leaving no stone unturned in the quest for robust security.

StackHawk's alignment with the conference theme of API Security Testing underscores our commitment to staying ahead of the curve and our dedication to developing solutions that resonate with the current needs and challenges faced by the industry. Whether it's a new feature like GitHub Insights Beta or the intelligent use of existing functionalities, we are poised to empower organizations in their API security efforts.

Conclusion

BlackHat 2023 was more than just an event; it was a melting pot of ideas, a validation of our approach, and a source of inspiration for future endeavors. As we reflect on our time spent demoing StackHawk to an engaged audience of security professionals, a few key takeaways stand out:

Understanding and Relevance: Our discussions and demonstrations provided insight into the growing relevance of DAST, and specifically, how StackHawk's developer-friendly approach fills a unique need within the industry.
Exciting Features and Reactions: From StackHawk’s streaming results to our GitHub Insights Beta, we were able to showcase features that not only resonate with our users but also position StackHawk as a forward-thinking leader in application and API security testing.
Community and Connection: Engaging with attendees, sharing stories, and building connections reinforced the value of community. We were reminded that our work at StackHawk is not just about creating tools but also about nurturing relationships and contributing to the broader security landscape.

Reflecting on BlackHat 2023, it's clear that the event was a valuable opportunity for StackHawk to align with the pulse of the industry, validate our innovations, and forge connections that will fuel our future growth.

Take the Next Step with StackHawk

If our experience at BlackHat resonates with you, or if you're intrigued by what StackHawk has to offer, we invite you to explore further:

Request a Demo: Experience the power and simplicity of StackHawk's platform by getting in touch for a personalized demo. Discover how we can tailor our solutions to meet your unique security needs.
Register for GitHub Insights Beta: Join our beta program and be among the first to experience our new GitHub Insights feature. Your participation will not only provide early access but also shape the future of this exciting development.

At StackHawk, we're driven by a vision of making security accessible, efficient, and integral to the development process. Our time at BlackHat 2023 has only strengthened this vision, and we look forward to what the future holds. Join us on this journey and be a part of shaping a more secure digital world.

Brian Erickson is a Sr. Product Manager at StackHawk

Austin Pearigen is a Software Engineer at StackHawk

Zachary Conger is a Solutions Architect at StackHawk

Understanding the Attack Surface of a Production API

Dan Hopkins

Finding, fixing and preventing security vulnerabilities from entering production requires understanding the scope of what you’re protecting. When it comes to APIs, this information is often hard to get, out of date, or incomplete. Like the blind men trying to understand the elephant, the stakeholders involved with developing and operating an API understand the system in different ways. Often referred to as the “three lenses of production”, it’s important to understand the various roles and responsibilities each stakeholder plays to further understand where information overlaps and where attention to detail may be lacking.

Three Lenses of Production

When we dive into the various stakeholders responsible for understanding API attack surfaces, they fall into these three key roles: Engineering, QA, and Security. Each has their own unique role, which we’ve outlined below:

Engineers understand how code is written and the routes that exist. They often communicate in documentation such as OpenAPI specifications. Given the speed of software development, these documents can be challenging to maintain and at times, can be out of date or incorrect.
QA teams understand how the system actually works, but they usually don’t test the entirety of the API due to time constraints. They document their knowledge using automated testing frameworks like Selenium or Cypress tests.
Security teams monitor production to ensure that no one is attacking the system. They have insight into how users are using the system, but they might miss long-tail routes that get called infrequently. Their knowledge can be stored in API Security tools such as Salt Security, Tenable, or NoName.

Integrate API Security with StackHawk’s API Security Testing

If using tools like Salt Security or Traceable you can export an OpenAPI Specification based on the real API requests logged by the monitoring system. With your newly created OpenAPI Spec, you can test your website by configuring HawkScan. Note: Since you’re likely protecting your production server using an API Security tool, take care to not run your StackHawk tests on production. Make sure that you edit your tests to run against your preproduction system. If you copy URLs directly from production, ensure that the domains have been adjusted to point at pre-prod.

This process of extracting an OpenAPI Spec from your API Security system and connecting it to the testing pipeline is also something that is worth automating to connect to your API security system and extract a new OpenAPI spec whenever your scan runs. This will ensure that you are always running against a recent version of your API specification.

Understanding Your API Attack Surface: Best Practices

When it comes to comprehending your API's potential vulnerabilities, there are key steps that developers and security professionals should prioritize.

Begin by examining the API's routes and operations, as this provides a fundamental understanding of its functionality. Next, delve into the specifics of the data flowing through the API. This involves integrating this data into your testing strategy to replicate realistic scenarios.

A valuable strategy is to leverage attack data collected from your API Security tools. This data can be replayed across your entire system, extending beyond the original points of attack.

Consider a scenario where your security team detects an attempt to exploit a common SQL injection vulnerability in a user creation form. If the user creation form is utilized in various parts of your enterprise, you can efficiently assess your system's safety by applying the known attack technique across numerous API endpoints using custom data.

Build a Strong AppSec Program

When dealing with data from production systems, exercise caution to avoid transferring customer or personally identifiable information from production to pre-production environments. Adhering to corporate compliance controls is essential, and it's wise to keep sensitive data separate. Nevertheless, this doesn't hinder your ability to utilize attack data, which doesn't contain sensitive details.

Remember, the essence of shifting security left is to detect vulnerabilities prior to their introduction in production. While API Security systems might not be aware of new functionalities until deployment, this presents an opportunity for enhancement. You can establish procedures that grant your team insights into upcoming or modified APIs, allowing thorough testing before reaching the production phase.

By being vigilant and proactive, you're ensuring a robust security approach that benefits both your team and the overall system integrity.

Summary

Connecting your API Security system to your API Security Testing program means that you will more fully understand the surface area of what you’re testing and can prioritize APIs that contain sensitive data. See how StackHawk stands out as one of Salt Security’s inaugural partners implementing this technique.

Dan Hopkins is VP of Engineering at StackHawk

Read more:

Multiple Cookies and Token Authentication: Enhancing API Security

Alberto Fidalgo

Authentication is a critical aspect of software development, ensuring that only authorized users can access sensitive information or perform specific actions. While traditional username and password authentication has long been the norm, modern software solutions are increasingly adopting more advanced methods, such as multiple cookies and token authentication. These techniques not only bolster security but also provide a seamless user experience. In this blog, we will explore the benefits and applications of multiple cookies and token authentication in software.

What is Multiple Cookies and Token Authentication?

Multiple cookies and token authentication involve using custom tokens or cookies to authenticate users instead of relying solely on a username and password. These tokens or cookies act as authorization credentials, granting access to specific resources or functionalities within an application.

Tokens are typically used in API key access or third-party authentication services like OAuth. They are generated by the server and provided to the client, who includes them in subsequent requests to prove their identity. Cookies are also generated by the server as small pieces of data stored on the client side and sent with each request to the server.

Benefits of Multiple Cookies and Token Authentication

1. Enhanced Security: Tokens and cookies provide an additional layer of security by separating authentication from the actual user credentials. This reduces the risk of exposing sensitive information, such as passwords, during the authentication process.

2. Scalability: Tokens and cookies can be easily generated and managed, making them ideal for scenarios where multiple users need to access an application simultaneously. This scalability ensures that the authentication process remains efficient and reliable.

3. Third-Party Integration: Many applications rely on third-party authentication services like OAuth. By supporting multiple cookies and token authentication, software can seamlessly integrate with these services, providing a seamless user experience.

4. Granular Access Control: Tokens and cookies can be tailored to grant specific permissions or access levels to different users or user groups. This fine-grained control allows for more precise authorization and reduces the risk of unauthorized access to sensitive resources.

Implementing Multiple Cookies and Token Authentication

To implement multiple cookies and token authentication in your software, you can leverage the capabilities of HawkScan, a powerful security testing tool. HawkScan allows you to supply authorization tokens or cookies externally through its `authentication.external` configuration.

The configuration consists of three main parts:

1. Logged In/Out Indicators: These indicators help HawkScan determine if it is logged in throughout the scan. You can define regex patterns or HTTP response codes that indicate a successful login or logout.

2. Auth(Z) External Injection: This section allows you to specify the tokens or cookies that will be injected into each request sent by HawkScan. You can define the type (TOKEN or COOKIE), name, value, and optional token type for each token or cookie.

3. Test Path: HawkScan needs a test path to verify if the authentication was successful. This path should only be accessible when the user is logged in. You can define the path, expected success response pattern, and request method (GET, POST, etc.).

By configuring these sections in your `stackhawk.yml` file as shown below, you can seamlessly integrate multiple cookies and token authentication into your software.

Multiple cookies and token authentication provide enhanced security and flexibility for API-driven applications. By leveraging tokens or cookies as authorization credentials, you can ensure that only authorized users can access sensitive resources or perform specific actions. HawkScan's support for multiple cookies and token authentication makes it easy to test even the most gated paths of your application.

Secure Code in the Age of AI: Challenges and Solutions

Joni Klippert

The pace of AI-based technologies is growing faster than any technology we’ve yet to see. It has sparked curiosity into the elements of how AI and Large Language Models (LLM) tools can help drive innovation and improve efficiencies industry-wide and has offered some playful observations, such as asking ChatGPT to describe the value of StackHawk as if it were The Godfather.

Playfulness aside, the software industry is rapidly adopting new solutions that incorporate generative AI to drive innovation and provide more value to customers at an accelerated rate. Recently, the R&D and Marketing teams at StackHawk wrapped our own AI-focused hack-a-Thon, with a focus on driving innovation into our everyday practices utilizing various AI and LLM solutions. It was a pretty exciting week, and I’m looking forward to sharing our learnings at a later date (intentional teaser, stay tuned). However, as the excitement continues to unfold, we are very mindful of ensuring secure code, after all, we should be, we’re a security company.

Security implication of using AI

As our news feeds fill with new solutions and company pitches backed by GenAI and LLM-based technologies, we continue to proceed with caution as we see evidence that using GenAI in code introduces more security vulnerabilities for many organizations. In a recent survey published by Snyk, they shared the following:

“On one hand, just over three-quarters of respondents (77%) said AI tools improve code security. At the same time, however, 59% are concerned that AI tools trained using general-purpose large language models (LLMs) will introduce security vulnerabilities that first appeared in the code used to train them.”

The adoption of code AI reminds us of the adage “what’s old is new,” meaning that just as we’ve watched the rollout of email and spammer fraud, new technology will always have its place for those that use it for good and that those will try to manipulate it and use it in nefarious ways.

We will eventually reach a point where generative AI can provide developers with prescriptive feedback on what security issues to fix regarding the specific language and frameworks they work with, as our CSO Scott Gerlach mentioned recently. But we aren’t there yet, and the power behind AI and LLMs requires a new level of responsibility when developing secure code.

When Developers don’t understand the code they are copying and pasting, it’s easy to pull in vulnerable code unintentionally, making the need for continuous testing of your running applications even more crucial. Which, spoiler alert, DAST solutions like StackHawk are perfect for testing AI-generated code at run time.

DAST uniquely positioned to test & secure AI-generated code

APIs powered by generative AI present a new place for attackers to gain a toehold in disrupting the market. As organizations deploy new applications utilizing LLMs, a two-part combination of data and code is released, leading to the importance of security testing the running application. Static code security solutions such as SAST won’t help in this situation; testing applications at runtime is something only modern DAST solutions can perform.

The primary capability of DAST solutions is to send various iterations of data to an input and check its outputs for responses that might indicate a vulnerability. Testing how LLMs act upon input can only be tested by trying inputs and checking how the output behaves at run-time, a perfect match for DAST.

Another way to look at this is that LLMs are built to answer the same prompt differently. This non-determinism makes testing them difficult and requires a multitude of different inputs to run over a number of tests to validate they are probabilistically safe to deploy. This technique is similar to fuzzing applications and again points to DAST as a great testing solution.

With the rollout of the new OWASP Top 10 for LLM project, created to identify specific vulnerabilities based on LLMs, we believe that 6 of the 10 will benefit from DAST's very core testing concept.

API Security Testing & StackHawk

At its core, StackHawk was built to bridge the trust gap between AppSec and Developer teams to ensure the delivery of safe code faster. StackHawk focuses on testing APIs and web applications during runtime, prior to production, and gives engineering teams the ability to find and fix code more effectively while running in their CI/CD workflows. With the acceleration of new technologies built on AI and LLM, StackHawk’s DAST solution is well poised to continue to be a very critical part of the security landscape for testing and adopting a secure code mindset. Keep an eye on this space as we continue to share our learnings and discuss more.

Optimizing Security Scan for Speed and Accuracy

Lindsy Farina

Introducing StackHawk’s new Optimization Tips Panel

First of all, welcome back to the PM corner, I’m Lindsy Farina, senior PM here at StackHawk! If you read my previous article about the themes we saw at RSA this year, you’d know that DAST and shifting left are super “on-trend” for 2023 security teams. In this blog post, we will explore StackHawk’s new Optimization Panel that houses tips to enhance the speed and accuracy of your DAST scans, the core elements of kickstarting your shift-left journey. So, grab your team, and let’s dive in!

What’s an Optimization Panel and why do I need it?

Great question! If you are like a lot of customers, you created a couple of applications during your POV with the help of my wonderful colleagues here at StackHawk, but maybe don’t remember all of the configuration tricks they used to help you get those scans going. Since you aren’t creating new applications every day, we know that it is easy to forget a few things, but we are here to help!

The new Optimization panel highlights the enablement status of three key features, custom scan discovery, technology flags, and authentication, on every scan, thus ensuring you don’t miss a step for your newly created applications. It will also tell you if something changes and configuration was lost, so you always have the latest information about the current state of your scans.

What can I expect to see in StackHawk?

For customers on our Pro and Enterprise plans, you should now see the Optimization Tips panel on the right side of the scan details page for each scan. You will also see the same icon from the panel on your environment cards on the Applications page.

Configuration is Queen

While there are quite a few dials you can turn in your StackHawk configuration, we will focus on the three I mentioned above. Please note that while you may have enabled these features, it may take a few rounds of testing to ensure that the configuration is just right! Don’t be discouraged, and don’t forget to invite your teams to help you on the journey!

Scope the scan with Custom Scan Discovery

One of the primary steps in optimizing a DAST scan is to define the scope. With Custom Scan Discovery, you can take advantage of other dev tools to help the scanner discover all the paths of your application. StackHawk allows you to do this by passing traffic generated from your existing dev tools like a Postman collection, or Selenium, Cypress, and Playwright test suites.

Tune your tech and plugins

With StackHawk’s Technology Flags, you can tune HawkScan for the specific technologies in your application, such as database engines and software languages. By default, all tech flags are enabled for new applications. When you deselect technology flags for an app, you reduce the total number of tests the scanner will apply to your application, thus reducing scan time and false positives.
By default, HawkScan selection of plugins that correspond to common vulnerability tests. And while there are a few default policies you can choose from, the real power comes when you create a custom policy that is tailored to your application. Check out our latest improvements to the Policy Management feature. Note that this feature is not yet part of the Optimization Panel, but definitely worth your time to explore!

Authenticated Scanning

Many web applications require user authentication to access various pages. To effectively scan for vulnerabilities, you must test all paths, including the authenticated routes. Authentication configuration can be tricky, but we have quite a lot of documentation to help guide you through the process. And always remember that you can get help at any time via the “Get more help” link on the Panel!

How does it work?

Let’s walk through a simple before and after example using the common JavaSpringVulny app.

Unoptimized scan

In the first scenario, you’ll see the new Optimization Panel on the right is reporting that none of the optimization features are enabled for this scan and the results returned 13 paths and 6 vulnerabilities.

In this scenario, Hawkscan used the base spider to crawl the application to identify the paths and the yaml configuration only contains three lines (StackHawk applicationId, host, and env.).

Optimized scan

However, in the second example, you can see that we now have all optimization features enabled. The scan results returned show 23 paths (10 more than the previous scan) and fewer vulnerabilities. This means that not only was the scan able to find more paths, but the results became more accurate by eliminating the false positives that were present in the first scan.

For reference, the yaml file now contains the authentication block, the base spider is set to false, we have supplied a custom command to run a Postman collection, and all irrelevant Db Tech Flags are disabled.

Optimizing DAST for speed and accuracy is at the core of StackHawk’s vision, and absolutely crucial in the journey to shift security testing left in your development lifecycle. We hope you find the new Optimization Panel useful on your own company’s journey! StackHawk is committed to continuously delivering not only features, but also content like webinars and blogs to give you our thoughts on tips, tricks, and best practices.

To end, I want to thank the many customers who participated in our UX design sessions, we so greatly appreciate your feedback! And with that, this is an open invitation for all of our customers to reach out to me directly with your thoughts, comments, and ideas for how we can continue to improve and support you! We LOVE feedback, the good, the bad, and even, the ugly, so don’t be shy! Feel free to email me directly at lindsy.farina@stackhawk.com, ping via our shared Slack channels, or send a note via a homing Hawk!

And as per usual, remember that security is a team sport, so grab your developers and share the fun of optimizing!! KAAKAWW!!

[Lindsy Farina is a senior Product Manager at StackHawk]

Read more:

StackHawk + Atlassian: Working Together to Help You Shift Left the Right Way

Charles Sanders

What does it mean to ‘shift left’?

Not the literal definition - I think we all know that by now (but just in case you’re not sure, “shifting left” is the process of integrating security practices early in the software development lifecycle and we have a great blog here that tells you everything you need to know!).

But what does it actually mean to shift left? What does it mean to you as a developer and how would it impact your day and your process for shipping, testing, and delivering secure code?

Like a lot of phrases that get turned into buzzwords, over time they unfortunately lose some of their meaning, their oomph, their pizazz. That’s why it’s good to remember that there’s a really important concept embedded in the buzz term, “shift left” , which is to be proactive.

Shifting left is about taking a more proactive, and scalable approach to security. It’s about breaking down silos (another buzz term that’s worth reflecting on) and bridging the gap between security and development teams - opening up those lines of communication with the understanding that security is a shared responsibility.

This is why StackHawk was created. For us it’s not a buzzword, it’s our purpose and why we wake up and KaKaww! in the morning.

And that’s why we get super excited when we have partners, like Atlassian, that share our vision and work with us to improve team collaboration, increase visibility into security issues, and better enable organizations to shift left.

Announcing Security in Jira

Announced earlier this year and now generally available to all Jira Software Cloud users, Security in Jira helps Jira Software users collaborate on security at every stage of the development lifecycle. StackHawk is honored to be one of the few, select technology vendors to integrate with Security in Jira at this early stage.

"We’re thrilled to partner with StackHawk to surface their DAST and API security testing directly in Jira Software where developers plan and prioritize their work.", says Jeff Richards, Product Partnerships Lead at Atlassian.

Now available on the Atlassian Marketplace, the StackHawk app for Security in Jira gives development teams the ability to view vulnerability data from StackHawk within the new Security Tab in Jira. Users have the ability to create and link Jira issues making it even easier to triage and prioritize vulnerabilities as part of their existing development workflows, such as sprint planning. Additionally, StackHawk provides vulnerability context directly in the issue, giving a comprehensive view of the information needed to address the security concern.

Learn More

To learn more about Security for Jira or to download the StackHawk Security for Jira app, please visit the Atlassian Marketplace here.

To learn more about how StackHawk helps developers run and automate security testing as part of their traditional software testing workflows, sign up for a free, two-week trial here!

How StackHawk Meets Compliance Requirements for Highly Regulated Industries with Security Compliance Automation

StackHawk

In today's fast-paced digital landscape, meeting compliance requirements has become increasingly crucial for most organizations. This is especially true when operating in highly regulated industries such as finance, healthcare, and retail. As a result, businesses are looking to solutions that automate security compliance, in an effort to prioritize their security posture and reduce the risk of data breaches or regulatory penalties.

By focusing on building a strong application security, or AppSec, program, your organization can strengthen and solidify its overall security posture. Making sure the overall health and efficiency of the AppSec program is in a good spot, factors such as compliance requirements will fall into place. By building the cornerstones of a solid AppSec program, almost all requirements for compliance will be met by default.

But how does one go about actually building a strong AppSec program to ensure that these needs are met? This is where StackHawk comes in to help. By providing businesses with the tools they need to automate and scale while simplifying their security compliance processes, StackHawk can help to identify and assist developers in remedying compliance gaps. In this blog, we will explain what security compliance is across various industries, the consequences of not adhering to these standards, and how StackHawk can help to improve security outcomes when it comes to highly-regulated industries trying to meet the guidelines of security compliance. We will not only delve into StackHawk's innovative approach to dynamic application security testing and its relevance to security compliance automation but also showcase how it can help companies across various sectors stay ahead of the compliance curve.

By building the most robust dynamic application security testing tools in the industry and a deep understanding of industry-specific regulations, StackHawk is transforming the way organizations address not only their security challenges and drive their compliance goals. We will explore the key features and benefits of StackHawk's platform and demonstrate how it can be customized to suit the unique requirements of your business. This approach helps to ensure that your sensitive data remains secure and your organization remains compliant in an ever-changing regulatory landscape.

So, whether you're a seasoned compliance expert or just starting to explore the world of regulatory requirements, join us as we uncover the power of StackHawk's applications security automation and learn how it can help your organization effectively manage compliance while enhancing your overall security posture.

Understanding Security Compliance in Highly Regulated Industries

The first step to ensuring you’ve met the compliance needs of your industry is to fully understand them. Of course, there’s only so much we can cover in a single blog so further research is recommended, however, below we will cover the basics. Compliance requirements are essential for maintaining security and privacy standards in highly regulated industries. As such, below we will discuss some of the most common regulations and compliance standards, such as HIPAA, GDPR, PCI DSS, and SOX. Ensuring that your company is complying with these standards makes sure that sensitive data is protected as necessary and avoids the legal penalties that can come with non-compliance. Let’s dig into some of the most common standards and the details surrounding them.

Health Insurance Portability and Accountability Act (HIPAA)

One of the most talked about regulations in the US is achieving HIPAA compliance. HIPAA is a US regulation that aims to protect the privacy and security of patient medical records and other health information and has been in force since 1996. It applies to healthcare providers, health plans, and clearinghouses, as well as their business associates. In a technical forum, this can encompass how services are hosted, how data is encrypted in transit and at rest, and access control. In some settings, it may even affect how code is written.

Some key requirements for HIPAA compliance include:

Implementing administrative, physical, and technical safeguards to protect electronic protected health information (ePHI)
Establishing access controls to prevent unauthorized access to ePHI
Regularly monitoring and auditing systems to detect potential security incidents
Ensuring secure transmission of ePHI across networks

By following these requirements and guidelines, you can avoid some of the hefty penalties that would come with non-compliance. From a civil perspective, a breach of HIPAA compliance could lead to fines ranging from $100 up to $50,000 per violation up to $1.5 million per year for each violation category. The exact amount fined depends on the company's level of culpability and efforts to correct the violation. When it comes to criminal penalties, individuals who knowingly and willfully violate HIPAA regulations can face fines of up to $250,000 and imprisonment for up to 10 years.

General Data Protection Regulation (GDPR)

A more recent regulation, GDPR has had a major impact on technology and data since 2018 when it started being enforced. GDPR is a comprehensive data protection regulation that applies to organizations operating within the European Union or processing the personal data of EU residents. Its main objectives are to enhance privacy rights and provide better control over personal data. For companies that do any type of business with EU residents, GDPR is a big deal.

Some of the key points of enforcement within the GDPR regulation include:

Ensuring lawful, fair, and transparent processing of personal data
Limiting data collection to what is necessary for the specified purpose (data minimization)
Implementing appropriate security measures to protect personal data against unauthorized access, disclosure, or destruction
Reporting data breaches to the relevant supervisory authority within 72 hours
Obtaining explicit consent from data subjects before processing their data, unless another lawful basis applies

When it comes to non-compliance, fines are tiered, with the maximum fine being up to €20 million or 4% of the organization's global annual turnover, whichever is higher, for the most severe violations. Lesser violations can result in fines of up to €10 million or 2% of the organization's global annual turnover. Aside from the monetary penalties, data protection authorities can also impose other corrective measures, such as warnings, reprimands, and orders to comply with specific GDPR requirements. Non-compliance is taken very seriously, as seen in the penalties listed above.

Payment Card Industry Data Security Standard (PCI DSS) (H3)

Since 2004, PCI DSS has been the global security standard used to protect cardholder data in the payment industry. The standard came out of the need to standardize the different practices in place to protect cardholder information. Various standards at MasterCard, American Express, Visa, JCB International, and Discover Financial Services led to the creation and development of the PCI standards used today. PCI DSS applies to all entities involved in payment card processing, including merchants, processors, acquirers, and service providers.

Some key requirements of PCI DSS include:

Implementing strong access control measures to restrict access to cardholder data
Regularly testing and monitoring network resources and cardholder data environments for vulnerabilities
Maintaining a secure network by installing and configuring firewalls and routers
Ensuring the secure transmission of cardholder data across public networks
Implementing robust encryption methods to protect stored cardholder data

The fines that come with a breach or non-compliance with PCI DSS can range from $5,000 to $100,000 per month for non-compliant merchants. The exact fine depends on the level of non-compliance and the duration of the violation. The more significant consequences are potentially increased transaction fees, damage to the organization's reputation, and even the revocation of the organization's ability to accept card payments.

Sarbanes-Oxley Act (SOX

The last compliance standard we will look at is the Sarbanes-Oxley Act, usually shortened to SOX. SOX is a US federal law enacted to protect investors from fraudulent accounting activities by corporations. SOX applies to all publicly traded companies and also applies to their auditors. While SOX primarily focuses on financial reporting and corporate governance, it also has implications for IT security and operations.

A few key SOX requirements include:

Establishing and maintaining internal controls over financial reporting (ICFR)
Regularly assessing and testing the effectiveness of ICFR
Ensuring the secure storage and retention of electronic records and audit logs
Implementing access controls to prevent unauthorized access to financial data and systems
Protecting sensitive data through encryption and other security measures

The consequences of non-compliance with SOX include both civil and criminal penalties.

Civil penalties include significant fines, with CEOs and CFOs personally liable for financial statement inaccuracies. The fines imposed for violations can range from $1 million to $5 million.

Criminal penalties for individuals who knowingly and willfully violate SOX regulations can face imprisonment for up to 20 years, depending on the specific violation.

Understanding and complying with these common regulations is crucial for organizations operating in highly regulated industries. By implementing the necessary security measures and best practices, businesses can safeguard sensitive data, maintain customer trust, and avoid costly penalties.

In addition to the fines and penalties discussed above, organizations that fail to comply with regulatory requirements may also suffer reputational damage, loss of customer trust, and potential legal action from affected parties. For large and publicly exposed infractions, the damage could lead to an organization completely going under and dissolving. Consequently, organizations need to prioritize compliance with these regulations to avoid costly consequences and maintain a strong security posture. Most companies who fall under these regulations publicly declare their compliance to instill trust within their customer base.

StackHawk's Security Compliance Automation Features

StackHawk's various features for improving application and API security via automation provide organizations with the tools they need to efficiently manage and maintain compliance with various regulatory requirements. By automating security compliance checks and monitoring, StackHawk streamlines the process of identifying and addressing vulnerabilities. By implementing a dynamic application security testing (DAST) tool, StackHawk automatically tests APIs and applications to that organizations maintain a strong security posture.

Key features of StackHawk that can be used as part of security compliance automation include:

Continuous Testing

StackHawk’s platform offers dynamic application security testing for web applications and APIs offering automated and continuous testing during the development stages to identify security vulnerabilities in real-time and prior to deployment. This proactive approach helps organizations address potential vulnerabilities and compliance issues as well as requirements such as PCI 6.6. By doing this, companies can reduce the likelihood of data breaches and security incidents that could lead to non-compliance with regulatory requirements.

Automated Reporting

StackHawk generates detailed and comprehensive reports of its security scans, providing a clear record of the application vulnerabilities detected and level of severity which may affect security and compliance. These automatic reports not only help organizations maintain a clear view of their security posture but also serve as valuable evidence during audits. When a vulnerability is remedied and code is committed, StackHawk will scan the application again to ensure the vulnerability is fixed. This functionality can help organizations demonstrate their commitment to maintaining compliance and creating secure applications.

Integration with CI/CD Pipelines

StackHawk takes DAST and security testing automation to the next level by integrating directly into a CI/CD stack. StackHawk is designed to fit seamlessly into existing Continuous Integration/Continuous Deployment (CI/CD) pipelines, embedding security testing within the software development process. By adding StackHawk as a step in the CI/CD pipeline, development teams can automatically run security scans on their applications whenever code changes are pushed into a repository. This ensures that vulnerabilities are detected and addressed early in the development lifecycle when the code is first created and added to the application. This “shifting left” of security puts the onus on developers to make the fixes and create secure code, minimizing the risk of non-compliance and reducing the time and effort required to remediate issues.

Customizable Scans

The ability to customize scans is another feature that makes StackHawk a great way to ensure you are covering all the bases during development. By configuring the platform to meet the unique security and compliance requirements of their industry, organizations can ensure that their applications and infrastructure adhere to the relevant regulations. Customizing the scans is easy to do and allows organizations and developers to dial in their automated testing efforts to ensure security requirements are met, no matter how complex or obscure.

Developer-Centric Insights

StackHawk is built with developers in mind, providing clear and actionable insights that enable quick remediation of vulnerabilities. By empowering developers to address security and compliance issues within their existing workflows, StackHawk helps organizations maintain compliance more efficiently and effectively. Within every vulnerability report, there are suggestions and links to aid developers in understanding, reproducing and fixing found vulnerabilities easily. Developers can move from testing to understanding, to fixing. Issues that can be fixed later can be added to a ticket for tracking in their favorite tool, such as Jira. By easily integrating into familiar developer workflows, StackHawk offers developers an augmented security experience on their home turf.

Integrating StackHawk with Existing Systems and Processes

As mentioned in the previous section, StackHawk is designed to easily integrate with existing systems and processes. This ability makes it a seamless addition to an organization's security and compliance workflows. StackHawk’s platform has been built with developers in mind and offers integrations with popular developer tools, compatibility with various programming languages and platforms, and the ability to fit into existing CI/CD flows. This makes developers love our product since it ensures that StackHawk can enhance security practices without disrupting established processes. Let’s take a deeper dive into each of these areas.

API and Integrations with Popular Tools

For a tool to be easily adopted, it needs to fit into the current architecture and tooling that an organization is using. The StackHawk API exposes an OpenAPI specification that can be referenced for automation or research purposes. StackHawk's API allows organizations to easily integrate the platform with their existing systems and applications for ultimate flexibility.

Beyond the API, StackHawk offers out-of-the-box integrations with popular tools like Jira, Slack, and GitHub. These integrations enable streamlined workflows and improved collaboration between development and security teams. The result allows organizations to address vulnerabilities more effectively and maintain their compliance most efficiently within their common workflows. As StackHawk and the developer landscape evolve, StackHawk continues to build integrations with tools the developers love to make sure developers get the best experience possible, making DAST accessible and effective.

Compatibility with Various Programming Languages and Platforms

StackHawk is agnostic to web programming languages and platforms, ensuring that organizations can use it regardless of their technology stack. This flexibility enables businesses to leverage StackHawk's security testing capabilities without needing to make significant changes to their existing infrastructure or development processes. In the vulnerability reports that StackHawk generates, fix guides are also provided in a variety of languages to help users identify and implement fixes quickly.

Integration with Existing CI/CD Flows

The key differentiator for StackHawk’s modern DAST solution is the ability to fit nicely into existing CI/CD workflows. StackHawk is designed to fit seamlessly into existing Continuous Integration/Continuous Deployment (CI/CD) pipelines, allowing organizations to embed security testing within their software development process. By adding StackHawk as a step in the CI/CD pipeline, development teams can automatically run security scans on their applications whenever code changes are committed and pushed to a repository.

Setting up StackHawk within a CI/CD pipeline is simple and generally only requires a few steps. At a high-level, integrating StackHawk into a CI/CD pipeline looks like this:

a. Install StackHawk's scanner (HawkScan) in your CI/CD environment.

b. Configure the scanner by creating a `stackhawk.yml` configuration file, specifying the application details, target environment, and relevant security tests.

c. Add a step to your CI/CD pipeline to run HawkScan whenever code changes are pushed, using the configuration file created earlier.

d. Monitor the results and integrate them into your existing notification, issue tracking, and reporting processes.

For more details on this integration, check out our in-depth docs or contact our team.

StackHawk's flexibility and compatibility make it an ideal solution for organizations looking to enhance their security and compliance processes without disrupting existing workflows. Its API, integrations with popular tools, support for various programming languages and platforms, and seamless integration with CI/CD pipelines ensure that StackHawk can be easily adopted and implemented by development and security teams, fostering a proactive approach to security and compliance management.

StackHawk's Role in Simplifying Compliance Audits

StackHawk plays a pivotal role in simplifying compliance audits for highly regulated industries, such as those subject to HIPAA, PCI DSS, and other regulatory frameworks. Its automated documentation and reporting features, along with its proactive approach to ensuring compliance requirements are met, help streamline the audit process. By helping to ensure compliance and application security, organizations will benefit from the reduced chances of penalties and fines. StackHawk can help with supplementing compliance audits with the following ways:

Automated Documentation

StackHawk's platform generates detailed and comprehensive documentation of its security scans, providing a clear record of the vulnerabilities detected, remediation efforts, and any outstanding issues. This automated documentation not only helps organizations maintain a clear view of their security posture but also serves as valuable evidence during audits, demonstrating their commitment to maintaining compliance.

Reporting Features

StackHawk offers user-friendly reporting features that make it easy for organizations to review, analyze, and communicate their security findings. These reports can be tailored to the specific requirements of different regulatory frameworks, helping organizations present relevant information clearly and concisely during audits. Additionally, these reports can be easily shared with auditors, further streamlining the audit process.

Ensuring Compliance Requirements Are Met

StackHawk's continuous monitoring capabilities allow organizations to proactively identify and address vulnerabilities in real time, reducing the likelihood of data breaches and security incidents that can lead to non-compliance. By continuously testing applications and APIs, StackHawk helps organizations ensure they adhere to the security requirements set forth by regulations like HIPAA and PCI DSS.

Customizable Scans

As mentioned previously, StackHawk's platform can be customized to meet the specific security and compliance requirements of different industries and regulations. By configuring the platform to focus on the relevant security controls and standards, organizations can ensure that their applications and infrastructure meet the stringent requirements of their respective regulatory frameworks.

Real-World Examples of StackHawk in Highly Regulated Industries

By continuously testing web applications for potential security vulnerabilities, StackHawk can effectively minimize risks and ensure compliance with industry-specific regulations. DAST tools can be utilized by almost every application to uncover vulnerabilities. The wide applicability of StackHawk means that it can have a positive impact on the security of applications across many different verticals. Here are some real-world scenarios in which StackHawk’s DAST tool can be effectively utilized:

Financial Services Industry

Banks, credit unions, and other financial institutions must adhere to strict regulations such as GDPR, GLBA, and PCI DSS, including PCI 6.6 which emphasizes security for web applications. StackHawk can automatically and continuously monitor web applications and API code for security vulnerabilities. By adding StackHawk into the development process, the protection of sensitive customer data and maintaining regulatory compliance at the code and application level can be ensured.

Healthcare Industry

As we saw earlier, healthcare providers must comply with regulations like HIPAA and HITECH to protect patient information. StackHawk can automatically test Electronic Health Record (EHR) systems and patient portals for security issues and identify these to the developers building the applications. This means that by the time the system hits production security vulnerabilities are remedied and confidential patient data remains protected.

E-commerce and Retail Industry

Although we tend to see a lot of breaches in this sector, online and brick-and-mortar retailers must comply with PCI DSS to protect customer payment information. Automated testing and reporting through StackHawk can identify vulnerabilities in e-commerce platforms and payment gateways. This automation can help businesses maintain compliance, protect customer data, and retain customer trust which can be shattered by a single breach.

In each of these scenarios, StackHawk can provide continuous testing to identify security vulnerabilities, helping organizations in highly regulated industries scale application security compliance via automation. By integrating StackHawk into the software development lifecycle (SDLC) and existing workflows, these industries can efficiently address security concerns, minimize risks, and stay compliant with ever-evolving regulations.

Ensuring Ongoing Compliance with StackHawk's Continuous Testing

Since applications are forever changing and new code is committed daily, even hourly, continuous testing through automated DAST testing is essential. Continuous testing of application code is essential for maintaining compliance in the face of an ever-evolving regulatory landscape. Many companies view testing as something done when applications hit production but when it comes to security, this is often too late. By testing and reporting on the security of an application, as it is being built, potential security issues at the application level can be handled immediately. The importance of the continuous testing of applications with StackHawk can be highlighted through the following key points:

Detecting Vulnerabilities in Real-Time

By continuously testing an application’s security as it is being built, organizations can promptly identify security vulnerabilities in their applications. This proactive approach enables them to address these vulnerabilities before they can be exploited by malicious actors. Proactively identifying and fixing vulnerabilities before they hit production helps reduce the likelihood of data breaches and ensures ongoing compliance with regulatory requirements that can be verified through StackHawk. Layering StackHawk with other security testing tools such as a static application security testing tool, like Snyk, and monitoring tools, such as Sentry, can help to build a well-rounded security framework.

Adapting to Changing Regulations

As regulations evolve to address new security threats and technological advancements, organizations must adapt their security practices accordingly. Continuous testing allows businesses to stay informed about changes in regulatory requirements and adjust their security posture as needed, ensuring ongoing compliance and reducing the risk of non-compliance penalties. With StackHawk, if regulations change, testing can be customized to meet the new requirements. Once the customization is live, future code flowing through the CI/CD pipeline will be tested to meet these new requirements.

Supporting DevOps and Agile methodologies

Modern software development processes, such as DevOps and agile methodologies, emphasize rapid deployment and continuous improvement. Continuous security testing, including StackHawk’s DAST tool, aligns with these processes by providing real-time feedback on potential vulnerabilities through robust reporting and integration with other tools like Jira and Slack. With this approach, development teams are enabled to address issues quickly and maintain compliance throughout the software development lifecycle. By implementing a “shift left” approach to security testing and integrating it into automated developer workflows, StackHawk can ensure that applications are compliant earlier in the development lifecycle.

Demonstrating Due Diligence

By implementing continuous testing, organizations can demonstrate their commitment to maintaining a robust security posture and adhering to regulatory requirements. This not only helps avoid fines and penalties but also builds trust with customers, partners, and other stakeholders. With StackHawk, reports are generated with every scan so the security of an application and the development efforts to improve it are well documented. This security due diligence, especially being applied early in the software development lifecycle before code hits production, helps assure customers that an organization takes data security and regulatory compliance seriously.

Streamlining Audits and Reporting

As mentioned previously, continuous testing generates a wealth of data on an organization's security practices and compliance status. This information can be invaluable during audits, simplifying the process of demonstrating compliance to regulators and reducing the time and resources needed to complete the audit. StackHawk’s reports are retained as long as your StackHawk subscription is active, giving the customer flexibility to delete scans and report data at their leisure. This retention period also offers an audit trail for security compliance that can easily be traced back even if audits dig deep into an application’s security history. Generating a report to outline the current status of an application is done upon every commit so seeing trends from the past up until the most recent commit is easy to do.

To wrap up this section, continuous testing is crucial for organizations looking to maintain compliance in a constantly changing regulatory environment. By implementing security testing tools like DAST, businesses can effectively and efficiently identify and address application vulnerabilities, adapt to new regulations, and demonstrate their commitment to maintaining a strong security posture.

Conclusion

In conclusion, security testing automation is a critical aspect of maintaining a robust security posture and adhering to regulatory requirements in highly regulated industries. StackHawk, with its innovative approach to dynamic application security testing and the ability to continuously test for vulnerabilities in an application as it’s being built, offers a powerful solution for organizations looking to streamline their application security processes and stay ahead of potential compliance issues.

By leveraging StackHawk's platform, businesses can benefit from run-time vulnerability detection in their code as an application is being built. Through seamless integration with CI/CD pipelines, developer-centric insights, comprehensive API testing, and streamlined reporting and auditing, StackHawk helps companies stay secure and compliant by “shifting left” the burden of application security. These features not only help organizations meet the stringent compliance requirements of regulations like HIPAA, GDPR, PCI DSS, and SOX but also reduce the risk of costly fines, reputational damage, and legal consequences. By detecting vulnerabilities early, applications are also more secure out of the gate and cost less to build and maintain.

With its focus on security compliance automation and adaptability to the unique needs of highly regulated industries, StackHawk empowers organizations to build secure applications, safeguard their sensitive data, and maintain customer trust. To try out StackHawk for yourself, sign up today for a 14-day free trial to “shift left” and get a jumpstart on meeting compliance requirements through automation.

Scaling Security Across Applications: Best Practices and Strategies

Brian Erickson

Scaling security across multiple applications is a challenge that many organizations face. Whether it's deploying a new application security tool or optimizing existing processes, the task of rolling out security measures across a large number of applications can be complex and time-consuming.

In this blog post, we will explore the best practices and strategies for scaling security across many applications. We will delve into the principles of operations and software engineering and discuss how they can be applied to application security. Additionally, we will highlight the use of configuration files, environment variables, and overlays to achieve scalability with modularization. Let's dive in!

Principles of Scaling Application Security

We believe in three fundamental principles for scaling application security:

1. Dry Development: The "Don't Repeat Yourself" (DRY) principle encourages developers to avoid duplicating configuration settings. By breaking down long configuration files into reusable modules, developers can improve readability, reduce maintenance costs, and achieve consistent results across applications.

2. Source Control: Just like source code, configuration files should be managed in version control systems such as Git. This practice ensures everyone has access to the same configuration version and simplifies troubleshooting in case of issues.

3. Local Scanning: StackHawk's Scanner can run locally, close to the running code, enabling engineers to discover and fix vulnerabilities before they make another pull request. This iterative process of making changes, testing, and repeating allows for rapid progress in resolving security issues.

Now let’s see how you can apply these principles to achieve a scalable and efficient AppSec program.

Utilizing Configuration Files and Environment Variables

Environment variables store application-specific values like connection settings and security credentials, allowing for dynamic injection of the correct values at runtime. This flexibility simplifies configuration management across different environments and enables developers to run scans without extensive configuration knowledge.

Setting environment variables with default values also helps ensure developers can easily run scans without explicitly configuring each variable.

Check out this step-by-step guide on utilizing YAML configuration files and environment variables with HawkScan.

Implementing Overlays for Modularization

Overlays are a powerful feature in StackHawk's HawkScan tool that enables the extension and modification of base configuration files. By breaking down configurations into separate YAML files, developers can modularize their settings, making them shareable across different applications. Overlays can include common configurations for authentication, custom scan discovery, test scripts, and more.

Overlays can be specified at scan time through command-line parameters or in CI/CD pipelines. This modular approach to configuration allows for scalability across multiple applications while maintaining consistency and reducing redundancy.

Check out this article to learn more about what overlays are, how to use them in your HawkScan configuration, and best practices to follow.

Scaling Across Teams

To roll out this approach to multiple teams, StackHawk offers two options: Git submodules and remote URLs (coming soon!). Git submodules enable centralized management of common configurations and can be shared across applications and teams. Alternatively, we are adding support to reference overlay files via remote URLs, allowing a centralized location to host overlays.

Scaling security across all of your applications is a critical undertaking for organizations aiming to maintain robust application security practices. By applying the principles of operations and software engineering, leveraging configuration files, environment variables, and overlays, and involving the development team, organizations can achieve an efficient large-scale AppSec program.

Thought leadership provided by: Dan Hopkins, VP of Engineering, and Brian Erickson, Senior Product Manager at StackHawk

Read more:

RSA 2023: Themes and Observations

Lindsy Farina

Hello and welcome to PM Corner! I’m Lindsy Farina, Senior Product Manager here at StackHawk! Today I will be sharing a little about the themes we saw at this year’s RSA conference in sunny San Francisco!

Let’s start with the biggest theme: Shift left

Like many great buzz phrases that came before it, digital transformation being the most recent, the concept sounds great, but the execution feels nebulous. We all know it’s coming, we all know we have to do it, but being the first to take the step into the abyss is hard. I definitely got a sense that people are on the cusp of making moves, some are still shifting to the center, but others are still peeking from behind the curtain to see how it goes.

At StackHawk, we realized early that the key to a successful shift was teamwork. The organization as a whole needs to get on board with the concept and create, dare I say it, synergy with security and engineering teams. Ultimately, it should be less scary to take that first step if you have a support system to join you!

And no one is going to shift left with scans that take hours, no matter how enthusiastic they are about the buzz. It simply doesn’t make sense. It was fun to watch how excited RSA booth visitors were to see us demo a full scan in real time, kicked off directly from the IDE, that completed before we could finish our spiel about DAST!

DAST & SAST: The dynamic (and static) duo

Just like it takes a village to shift left, it also takes a winning tool stack to complete the loop. SAST with DAST are the Martha Stewart and Snoop Dogg power team that helps you quickly identify your most critical vulnerabilities, helping you cut down the noise and prioritize what truly matters. While many users started in the SAST/SCA world, things are evolving, and it’s clear from our conversations at RSA that DAST is top of mind. Being able to hit your application at runtime to see if those code-level vulnerabilities are truly exploitable is the hot ticket. Surfacing vulnerabilities early in the development phase with DAST, coupled with code analysis from our friends at Snyk, I’ll cheers to that!

Coverage, discovery, and accuracy, oh my!

But do you support…? The answer was YES! Consumers are looking for API coverage and we have it. With support for REST, SOAP, GraphQL, and even gRPC, StackHawk has you covered. Booth visitors also asked about taking advantage of the work they’d already put in to build swagger docs, Selenium test suites, Postman collections, etc. StackHawk’s extensive custom scan discovery options have you covered. Not only does this improve the accuracy of your results, but it is also going to help with scan times getting you even closer to the left!

The Wrap Up

While the glowing StackHawk logo and our cool t-shirts may have brought people into our booth, what kept them there was our live demo. Many asked us “What does StackHawk do?” thinking that was necessary to get our cool shirt, but then quickly realized that they truly were interested and wanted to learn more. Per my colleagues, the booth visitors this year had clearly done their homework about DAST and StackHawk, and were more prepared with questions on the themes above compared to the 2022 RSA attendees. Many prospects are still in early phases of sorting out their tool stack, their compliance needs, and their course of action to get to building and deploying secure software. But it is clear that they are ready to take the steps toward shifting left, and see the value in what StackHawk has to offer. We are here for it!

[Lindsy Farina is a Sr. Product Manager at StackHawk]

Read more:

Top API Security Tools of 2025

StackHawk

Application programming interfaces, usually just referred to as APIs, are a very common attack vector when enterprises are breached. A poorly written and secured API endpoint can make an organization lose data and customer trust in the blink of an eye. As outlined in the OWASP API Security Top Ten, API attacks can have disastrous consequences for organizations and their customers. The risks present within APIs are why ensuring the security of an organization’s APIs is an important practice. Adhering to API security best practices and standards is a must for any organization exposing APIs internally and externally.

Luckily, there are numerous API security tools out there to help shoulder the burden of creating secure applications and APIs. Apart from the typical things such as cost, simplicity of integration, and ease of use, there are many other factors to consider when adopting new API security tools. Functionality should be at the top of the list and ensuring that the tool fits your exact needs within its features. Selecting the right API security tool involves evaluating capabilities such as API discovery, integration, testing, runtime protection, compliance, scalability, and maintenance to ensure comprehensive protection and alignment with the team's workflow. When selecting an API tool, it should be capable of performing one or more of the following tasks:

API security testing—The API tool must be capable of testing an API using the static application security testing (SAST) methodology, which involves testing the API source code for security flaws, or dynamic application security testing (DAST), simulating attacks to the API to check for security vulnerabilities.
API security posture—The tool should be able to create an inventory of APIs and the methods exposed and classify the data used by each method. This analysis provides visibility into the security state of a collection of APIs.
API runtime security—The tool should provide real-time protection for APIs against potential security breaches and attacks.

Ensuring secure APIs is crucial as it helps organizations proactively detect and manage vulnerabilities in their APIs. In this article, we’ll look at some of the most popular API security tools and how they can help you. Let’s start by looking at some key factors when it comes to API security!

What is API Security?

API security refers to the practices and protocols designed to protect Application Programming Interfaces (APIs) from unauthorized access, data breaches, and other malicious activities. APIs are critical in most modern software applications, enabling communication and data exchange between different systems, services, and devices. As such, they are a prime target for cyber attackers seeking to exploit vulnerabilities and gain access to sensitive data.

Effective API security involves a comprehensive approach that addresses the entire API lifecycle, from design and development to deployment and maintenance. This includes implementing robust authentication and authorization mechanisms, encrypting data both in transit and at rest, and conducting regular security testing. But what kind of threats are we looking at protecting against, and what risks do they bring?

API Security Threats and Risks

APIs are vulnerable to a range of security threats and risks that can have serious consequences for organizations. These include:

Unauthorized Access and Data Breaches: Attackers can exploit weak authentication mechanisms to gain unauthorized access to sensitive data.
Malicious Attacks: Techniques such as SQL injection and cross-site scripting (XSS) can be used to manipulate API endpoints and compromise data integrity.
Business Logic Vulnerabilities: Flaws like insecure direct object references (IDOR) can be exploited to access or manipulate data in unintended ways.
Denial of Service (DoS) and Distributed Denial of Service (DDoS) Attacks: These attacks can overwhelm an API, rendering it unavailable to legitimate users.
Man-in-the-Middle (MitM) Attacks: Intercepting and altering communication between APIs and clients can lead to data tampering and theft.
API Key and Token Theft: Compromised keys and tokens can provide attackers with unauthorized access to APIs.
Data Tampering and Manipulation: Attackers can alter data being transmitted through APIs, leading to data integrity issues.

Understanding these threats is crucial for security teams to implement effective countermeasures and protect sensitive data. Although some of these can be handled manually, there is a large list of great API security tools that can help developers to make APIs more secure. This can be done through either identifying issues within the API code or runtime issues, letting developers know where security gaps are and how to fix them. Let's get started by looking at seven of the most popular tools.

Top 7 API Tools of 2025

StackHawk

StackHawk is a modern API security testing tool founded in 2019. It's a dynamic application security testing (DAST) tool that scans APIs for potential vulnerabilities. StackHawk works by simulating an attack, which is based on common open-source vulnerabilities like OWASP top 10 or custom attack definitions, and observing how the API responds. In other words, it tries to leverage known vulnerabilities on the API to observe how it reacts to them to determine if the API is secure against the vulnerability or not.

Stackhawk provides seamless integration with your CI/CD so that you can automate the testing of every API endpoint in your application. By using StackHawk in your CI/CD pipeline, tests can be run on every commit to ensure developers are aware of any bugs in the codebase as soon as they are introduced.

Advantages of StackHawk

It integrates easily and provides extensive automation capabilities with your CI/CD, automating application testing quickly.
It offers test report analytics and dashboarding.
Helps inventory and prioritize APIs for security testing
StackHawk is built to test modern microservices infrastructure
Full support for all API types: REST, SOAP, GraphQL, and gRPC
Developer-first. Easy to scale application security across teams.
Integrations with popular dev-tools.

Disadvantages of StackHawk

Lacks an on-prem solution required by some industries and organizations.

ZAP

First on our list is ZAP. The Zed Attack Proxy, abbreviated to ZAP, is an open-source web security testing tool. The tool was developed by the Open Web Application Security Project (OWASP) and continuously maintained by the community to ensure it is up-to-date and effective against the latest threats.

ZAP's primary purpose is to provide penetration testing through automation. ZAP works by running simulated attacks against the API endpoint to check for exploitable vulnerabilities. By using this technique, ZAP lets developers know how their API will respond to an attack in real time. The result of these tests allows developers to implement security steps or refactor code to mitigate the discovered security defect.

ZAP is a cross-platform tool and can run on a variety of operating systems, including Mac OS, Windows, and Linux. The platform's primary language support is Java, but it also supports a variety of other languages such as JavaScript, JRuby, and other JSR 223 languages.

Advantages of ZAP

Free and open-source
Tests web applications and APIs against vulnerabilities outlined in the OWASP Top 10
Supports integration with various other platforms
Capable of generating test case reports

Disadvantages of ZAP

Could use more detailed test reporting functionality
Lacks automation support

Wallarm

Wallarm is an all-in-one API security tool that provides API security posture reports, security testing, and runtime protection.

Founded in 2014, it protects an API against runtime attacks, provides dynamic application security testing, and provides continuous API service discovery to give you an overview of your API inventory.

Wallarm integrates with any CI/CD workflow, allowing you to run dynamic test cases automatically.

You don't need a lot of programming experience to utilize Wallarm. It's a no-code tool hosted as a managed SaaS platform so Operating System compatibility is not a concern.

Advantages of Wallarm

It provides seamless integration with other platforms.
It's a full-suite API security tool.
It provides analytics and dashboarding of test reports.

Disadvantages of Wallarm

Very costly to run since pricing runs quite high.

42 Crunch

42 Crunch is a robust API security platform developed in 2016 to provide API security posture, automate API security testing in your CI/CD pipeline, and enforce security policies. 42 Crunch provides protection to APIs against threats in runtime through their firewall. The platform also provides auditing and discovery into your API inventory. From the API security testing standpoint, it provides static analysis testing for your APIs.

42 Crunch is a no-code SaaS platform, which means it's not dependent on any programming language and doesn't have any issues with OS compatibility.

42 Crunch also offers seamless interaction with many platforms, allowing you to automate security testing in your CI/CD workflow.

Advantages of 42 Crunch

It's a full-suite API security tool.
It provides integrations with your CI/CD workflow.
It provides analytics and dashboarding of test reports.

Disadvantages of 42 Crunch

Expensive since you are paying for a full suite of features, whether you use them or not.
It allows for fewer integrations with other platforms.

SALT Security

SALT is an API security platform founded in 2016 that provides continuous discovery and security posture management of all your APIs, including shadow and zombie APIs. This allows you to have the full context of your APIs and be aware of the data you're exposing. The platform allows you to scan and test your APIs for security vulnerabilities and protect APIs against runtime attacks.

SALT is a cross-platform software, meaning it can run on different types of operating systems and integrates seamlessly with your CI/CD workflow.

Advantages of SALT Security

It's a full-suite API security platform.
Provides integration with your CI/CD.
It provides analytics and dashboarding of test reports.

Disadvantages of SALT Security

Pricing is not transparent and not available on their website
No self-serve demo available

Postman

Postman is an API tool for creating and managing APIs. Within it’s suite of tools, Postman provides a testing solution that allows you to test your API for vulnerabilities. You can, for example, test your API to see if it has a broken authentication level or not.

It also has features that allow you to automate your security tests. With the potential to run your security tests within your CI/CD workflows.

Postman supports a variety of common languages and runs on Windows, MacOS, and Linux.

Advantages of Postman

great offering in the free tier, and paid tiers are still cost-effective.
It's cross-platform.
It provides analytics and reporting of tests.
It provides integration with different platforms.

Disadvantages of Postman

Integration possibilities are currently limited.

Imperva

Imperva is a cybersecurity software company founded in 2002 that offers an API security solution that includes API posture security and API runtime protection.

Imperva enables continuous deep discovery into your API inventory to eliminate data leakage and abuse. The platform allows users to be aware of what sensitive data they're exposing through their API endpoints, shadow APIs, and so on.

The company also uses a machine learning model to protect APIs in real-time against vulnerabilities in the OWASP top 10 and other new threats such as bad bot attacks, DDoS, credential stuffing, and so on.

Advantages of Imperva

It provides easy integration into your CI/CD.
Provides real-time API protection through machine learning models.

Disadvantages of Imperva

Has limited integration with other platforms.

API Security Best Practices

Regardless of the tools used, there are always some best practices you should adhere to when scaling up API security. To ensure the security of APIs, organizations should follow best practices that cover various aspects of API security, many of which the tools above can help with or help to detect issues with. These include:

Implement Authentication and Authorization: Almost all APIs should have some type of authentication and authorization in place for users. Use strong authentication mechanisms and ensure that only authorized users can access API endpoints.
Encrypt Data: Attackers can't exploit data they can't access. Protect data in transit and at rest using encryption to prevent unauthorized access and data breaches.
Conduct Regular Security Testing: There's no better way to be prepared than to continuously test your API's security. Perform dynamic application security testing (DAST) and other security tests to identify and mitigate vulnerabilities.
Rate Limiting and Throttling: Implement rate limiting to prevent abuse and ensure APIs are not overwhelmed by excessive requests.
Use Secure Protocols: Ensure APIs use secure communication protocols like HTTPS and TLS to protect data integrity and confidentiality.
Validate User Input: As one of the first steps in keeping your APIs safe, implement input validation and data sanitization to prevent injection attacks and other malicious activities.
Deploy a Web Application Firewall (WAF) and API Gateway: Use WAFs and API gateways to provide an additional layer of security and manage API traffic. This can help streamline many of the best practices listed above, including rate limiting and encryption.
Monitor API Traffic and Logs: Continuously monitor API traffic and logs for suspicious activity to detect and respond to potential threats. If something makes it through your defenses, set up alerts so you can remediate it ASAP.
Incident Response Plan: When something does go wrong, know what to do! Have an incident response plan in place to quickly address and mitigate the impact of security breaches.

By knowing and putting these best practices into action, organizations can significantly enhance their API security posture and protect their APIs from a wide range of security vulnerabilities. Whether preventing API security issues or detecting them after they have already occurred, a holistic strategy that covers as many angles as possible is the best defense (and offense) when it comes to protecting your APIs.

Final Thoughts

In this post, we looked at some of the top API security tools for your organization. Generally, a single tool will not cover every aspect of security so the best strategy is to layer tools for complete coverage. Although many platforms exist, each has its own advantages and disadvantages which may or may not be applicable to your use case. One thing to keep in mind when selecting an API security tool is to be certain about what you want out of the tool. For instance, if all you need is an API testing tool, there's likely no need to invest in a full API security suite. Other factors to consider are affordability, language and OS support, ease of use, and available integrations.

Whether you're just beginning to think about API security tools or are upgrading your existing suite, StackHawk offers an easy and affordable solution to implement dynamic application security testing. Plug StackHawk directly into your CI/CD pipeline or run it locally and identify potential vulnerabilities in minutes. Easily access reports and discover potential fixes from within the platform and level up your API security with ease and automation. To get started, sign up for your free trial today!

Additional resources

Read on to see how StackHawk's CSO, Scott Gerlach talks about “Shift Left” being more than just a buzzword here.
Check out why Omdia's On the Radar report highlights StackHawk as an “interesting alternative to most other DAST tools” here.
Getting started with StackHawk? Check out Advice and Answers from the amazing StackHawk team here.

Shifting Left: 8 Essential Tips to Evolve your AppSec Program

Alexa Sevilla

Implementing a Shift-Left Approach

Shift left is a concept that has been gaining traction in the cybersecurity industry in recent years, with the focus on incorporating security and security testing into the software development process early. The benefits of a shift-left approach include delivering secure code faster, reducing vulnerabilities in production, and driving efficiencies across AppSec and Dev teams.

In this blog post, we’ll explore the concept of shift left in more detail, as well as share two key resources that can help organizations learn best practices to implement it: "Shift Left: Beyond the Cybersecurity Buzzword" by Security Magazine, and RSAC Fireside Chat “StackHawk helps move the application security needle to ‘shift everywhere’” both articles featuring StackHawk’s CSO and security expert, Scott Gerlach.

What is Shift Left?

Shift left is a practice of incorporating security into the software development process as early as possible. Traditionally, security has been treated as an afterthought, with developers creating software first and security teams testing it later, either just before deployment or after it's been pushed to production. This approach is no longer sufficient. The speed at which software is developed and deployed today outpaces the ability for traditional approaches of security testing to keep up, and therefore can expose applications running in production to an increasing number of cyber attacks.

Shift left means that security is integrated into the development process from the start. This approach involves threat modeling, secure design, security testing and vulnerability assessments (to name a few) as early as possible in the development cycle. By identifying and addressing security issues early, organizations can save time and money and reduce the risk of a cyber attack being successful and the potential damage and interruption caused by one.

Shift left also involves a change in mindset. Rather than viewing security as a separate function, it is integrated into the development process, making it part of the development team's responsibility. This approach is commonly referred to as DevSecOps, and it involves a collaborative approach between development, security, and operations teams.

Shift Left: Beyond the Cybersecurity Buzzword

"Shift Left: Beyond the Cybersecurity Buzzword" is an article that provides a comprehensive overview of the shift left concept. The article explores the benefits of shift left, including early detection of vulnerabilities, cost savings, and improved overall security. It also discusses the challenges of implementing shift left, such as resistance to change and lack of expertise.

The article also offers practical guidance on how to implement shift left, such as involving the security team early in the development process, automating security testing, and providing training for developers on security best practices. The article emphasizes the importance of a collaborative approach between development, security, and operations teams.

RSAC Fireside Chat: StackHawk Helps Move the Application Security Needle to Shift Everywhere

The RSAC Fireside Chat is a podcast that discusses how StackHawk can help organizations implement shift left and improve their application security. StackHawk seamlessly integrates security testing into the software development process, making it part of the development team's responsibility.

The podcast discusses the challenges organizations face in securing their applications and how StackHawk can help organizations shift left and improve their application security. The podcast explores the features of StackHawk, such as automated API and application security testing. The podcast also emphasizes the importance of a collaborative approach between development and security teams.

How Can Organizations Implement Shift Left?

Implementing shift left requires a change in mindset and a collaborative approach between development, security, and operations teams. The following are some steps organizations can take to implement shift left:

Involve the Development Team Early in the AppSec Design Process

The development team must be involved and have buy-in for shift-left to work at all. Development teams need to help and accept design of process, selection of tooling, as well as ground rules for working agreements on how to partner with security teams. People, process, technology are what enable change. We often forget the people part of this formula.

2. Involve the Security Team Early in the Development Process

The security team should be involved in the development process from the beginning. This allows them to identify potential security risks early and provide guidance on how to mitigate those risks. By involving the security team early, organizations can save time and money by avoiding costly security issues later in the development process.

3. Implement a Self Service Approach

Be mindful of designing something that is a black box that developers can’t use or see. Empowering developers to be successful in the recreation of issues helps keep pace with the flow of development. If you’re breaking builds, and developers can’t easily recreate the issue or service their process, they will spend time to unwind it. That doesn’t mean don’t log decisions, but give developers the ability to make informed, action-based decisions.

4. Automate Security Testing

Automating security testing can save time and ensure that security testing is consistent and thorough. Tools like StackHawk offer a modern approach to application security testing by offering a platform that’s easily integrated into the existing dev workflows and CI/CD pipelines.

5. Provide Training for Developers on Security Best Practices

Developers should be trained on security best practices to ensure they are aware of potential security risks and how to mitigate them. This training can be provided by the security team or through external resources.

6. Conduct Regular Vulnerability Assessments

Regular vulnerability assessments can help identify security risks early in the development process. These assessments should be conducted by the security team or an external security provider.

7. Implement Continuous Integration and Continuous Delivery (CI/CD)

Continuous Integration and Continuous Delivery (CI/CD) can help ensure that security testing is integrated into the development process. CI/CD involves automating the building, testing, and deployment of software applications, which can help identify and mitigate security risks early in the development process.

8. Collaborate Between Development, Security, and Operations Teams

Collaboration between development, security, and operations teams is essential for successful implementation of shift left. The teams should work together to identify potential security risks and develop strategies to mitigate those risks.

Shift left is an essential concept that organizations need to adopt to improve their application security. By integrating security into the development process, organizations can identify and address security issues earlier, saving time and money in the long run. The resources mentioned in this blog post, "Shift Left: Beyond the Cybersecurity Buzzword" and RSAC Fireside Chat “StackHawk helps move the application security needle to ‘shift everywhere’” offer great guidance on how to implement shift left and improve application security.

Implementing shift left requires a change in mindset and a collaborative approach between development, security, and operations teams, but the benefits are significant and can help organizations stay ahead of the evolving threat landscape.

Learn more about StackHawk's security testing and how we can help your organizations improve application security best practices in order to shift left. We’d love to hear from you.

[Alexa Sevilla is the Director of Product Marketing at StackHawk]

Read more:

StackHawk named Winner in 2023 Global Infosec Awards at RSA 2023

StackHawk

DENVER, Colo. – April 24, 2023 – StackHawk, the company making web application and API security testing part of software delivery, announced today that Cyber Defense Magazine, the industry’s leading electronic information security magazine, has recognized StackHawk as a winner in the Next Gen API Security category in the 11th Annual Global Infosec Awards at RSA 2023. These prestigious global awards recognize innovators from any company stage with compelling value propositions for their products in competitive infosecurity industries.

StackHawk’s security testing platform empowers engineers to easily find and fix application security bugs at any stage of software development. Focused on pre-production API and web application security testing, StackHawk gives Development teams the ability to actively run security testing as part of their traditional software testing workflows, while giving AppSec teams the peace of mind of controlled and security tested applications in production. The platform works diligently to find security bugs earlier in the development process to avoid schedule disruption, identify high priority issues, and help developers fix security bugs prior to production at the accelerated rate of software delivery.

"StackHawk's recognition as a leader in next generation API security is a testament to our mission to enable developer success of building secure code, faster, " said Joni Klippert, CEO and co-founder of StackHawk. "This notoriety illustrates StackHawk's advanced product development and innovation throughout a market that is ready to adopt modern API security testing."

Built for modern engineering teams, StackHawk has reimagined API security testing by empowering developers to find and fix security vulnerabilities during their traditional build workflows. StackHawk believes in putting API and application security testing in the hands of the engineers who write the code, while bridging the trust gap among their AppSec counterparts with visibility and control. A developer-focused API security testing tool ensures more vulnerabilities can be addressed during the development stage of software delivery, reducing hours spent triaging bugs found in production, and helping scale AppSec teams.

"StackHawk embodies three major features we judges look for to become winners: understanding tomorrow’s threats, today, providing a cost-effective solution, and innovating in unexpected ways that can help mitigate cyber risk and get one step ahead of the next breach," said Gary S. Miliefsky, Publisher of Cyber Defense Magazine.

This announcement comes just on the heels of StackHawk’s recent expansion of API security testing capabilities to address large-scale enterprise customer needs -- providing enhanced optimization, scalability and governance controls. Join StackHawk’s webinar, “Scaling Security Across a Herd of Apps”, on Tuesday, May 16 at 10am PT to learn more about the company’s new enterprise capabilities. Register here.

Visit StackHawk at RSA

StackHawk will be a Bronze Sponsor at this year’s 2023 RSA Conference, located at the Moscone Center in San Francisco, CA from April 24-27. To learn more about the award-winning API security testing tool, visit StackHawk at booth #0767 in the South Expo Hall or click here.

About StackHawk

About Cyber Defense Magazine

StackHawk Media Contact:

Caitlin Kruell

Lumina Communications for StackHawk

stackhawk@luminapr.com

Cyber Defense Magazine Media Contact:

Irene Noser, Marketing Executive

marketing@cyberdefensemagazine.com

www.cyberdefensemagazine.com

Do You Trust Your X-Forwarded-For Header

Brandon Ward

`X-Forwarded-For` is Easy to Spoof

Here at StackHawk, we received several reports of security researchers being able to bypass our API rate limiting protection. At a high level, our rate limiter is keyed from the client IP address. What we discovered is that our API was accepting spoofed IP addresses via the X-Forwarded-For header.

This header is user controllable, so any values a user sends for this header will end up at the front. Users can send anything they like, from spoofed IP addresses to completely invalid values. It is up to us to sanitize and ignore the junk!

As we dug deeper, we realized that a misconfiguration in our API framework was causing it to always select the first value received via X-Forwarded-For, without any validation.

Let's explore some of the finer details of this header and look at how some popular cloud providers, application frameworks, and web servers handle it.

`X-Forwarded-For` Specification

The X-Forwarded-For header is intended to be used by proxies in your networking chain to track the IP address of the client from where the call originated. When a web request is made, the server receiving the request is aware of the IP address that is calling it. When using the X-Forwarded-For header, the receiving server should append the calling client’s IP address to the list of IP addresses in that header value. The resulting header might look something like this:

'X-Forwarded-For: <client>, <proxy1>, <proxy2>'

This diagram illustrates how the X-Forwarded-For header is built on its way to an API:

Mozilla provides the full specification for this header if you'd like to read more.

In a perfectly trusted environment, the first IP address in the list is the source IP address of the original client. The first IP address added by your proxy is the one you want to select. However, the world of software development is not a perfectly trusted environment. You can only trust what you can control.

Proxies servers do not clear this header by default, they only append to it. An attacker can generate requests with values for this header, and if you aren't careful, your application will use these false values.

Uses of `X-Forwarded-For`

There are a few ways we can leverage the values of X-Forwarded-For in our product or monitoring experience. It is important to have accurate values when doing so.

Audit logs - Many industries have complex audit requirements, including being able to identify who did something in the system. Even though an IP address alone is not definitive, it is an important breadcrumb to include in an audit log to ensure the actions occurring in your system are what you expect.
Rate Limiting - Although it is better to rate limit API calls from a user id, this only works when the user is logged in. If unauthenticated API calls are allowed, the only way to identify unique users is by their IP address.
Geo-location - IP addresses correlate to locations, and you can get a rough idea of where your user base is by correlating IP addresses to locations.

If we want to rely on IP addresses for any of these features, we must verify how this IP address is being selected to ensure we have an accurate value. For any of these features, allowing a spoofed or malicious IP address will break the value proposition of the feature.

`X-Forwarded-For` in Cloud Providers

Cloud providers follow the specifications of the X-Forwarded-For header, and many will default to append mode. Amazon Web Services (AWS) and Google Cloud Platform (GCP) will add IP addresses to the list by default, with zero validation or verification on existing IP addresses in that list. The important thing to highlight is that any existing X-Forwarded-For IP addresses are maintained at the front of the list.

There are also proxies you can run yourself, such as NGINX, which also lets you configure how X-Forwarded-For is handled. While NGINX is very configurable, their sensible default function behaves like AWS, which appends the remote address of the client to the list of header values.

It is important to highlight the differences between AWS and GCP in how they handle these headers. This illustrates that every situation is unique, and your situation will depend on your cloud provider(s), proxy server(s), and application framework(s) handling the requests.

AWS strictly appends a single IP address of the calling client to the X-Forwarded-For header. GCP will append two IP addresses, the IP address of the calling client, followed by the IP address of load balancer the request passed through.

AWS: 'X-Forwarded-For: <whatever-was-on-the-request-before>, <aws-detected-client-ip>'

GCP: 'X-Forwarded-For: <whatever-was-on-the-request-before>, <gcp-detected-client-ip>, <gcp-load-balancer-ip>'

Already we can see the divergence between major cloud players, and why parsing this header for an accurate value will be difficult. In both cases, <whatever-was-on-the-request-before> can be nothing, a value from an additional network proxy, or it could be malicious or spoofed values. The only commonality is that both append IP addresses to the original header value.

When you are a service provider with a publicly accessible API layer, requests originate from layers outside of your control. Whether this is your UI or direct API access, you cannot trust the request by default. Untrusted clients can put whatever IPs they like in the X-Forwarded-For header, which pollutes the values with spoofed or malicious data. Values in this header range from the most untrusted on the left to the most trusted on the right. We can only trust what we can control.

`X-Forwarded-For` Parsing Examples

Many popular application frameworks provide automatic parsing of this header, but your solution will ultimately depend on your specific environment. A naive approach to parsing this header is to simply grab the first one in the list. In a perfectly trusted world, that is the original client’s IP address. Don't actually do this in production, it is insecure.

Spring Boot

Spring Boot is a popular Java based application framework with many features. One of these features is automatic handling of the X-Forwarded-For header.

Spring Boot naively grabs the first value in the X-Forwarded-For header list, without any validation and no way to customize which value is selected.

Given what we know about the X-Forwarded-Header, Spring Boot will always select the spoofed IP address if it exists in the request. The default configuration is susceptible to consuming spoofed client IP addresses.

Tomcat

Tomcat is a popular Java based web server capable of handling the low-level concerns of running a Java application as a web service.

Tomcat has a better approach to parse X-Forwarded-For, where it walks the list of IP addresses in reverse order, looking for the first trusted IP address, while providing a mechanism to skip internal proxy IP addresses.

An example of an internal proxy IP address we want to skip would be the <gcp-load-balancer-ip> from above.

Tomcat will select a more accurate IP address, and can be configured to select the first trusted IP address, whether it is at the end of the list or somewhere in the middle.

In the case where we had multiple proxies in front of our application, Tomcat’s ability to generically filter out internal proxy IPs will lend itself to selecting the correct client IP address compared to Spring Boot which is too naive.

Configure Your Framework

We now know that Spring Boot will select the least trusted client IP address, but Tomcat will only select the correct client IP address if you describe internal proxies to it. Otherwise, it'll just extract the IP address at the end of the list. Depending on the final shape of your networking stack and the behavior of your proxy server, this could be an internal IP address.

If it's been a minute since you've verified your X-Forwarded-For configuration, or maybe you just accepted your framework's default implementation for this, now is the perfect time to verify how you use this header.

Lessons Learned

When underlying frameworks or platforms provide features, it’s common to use their implementation details without a second thought.

The nature of these frameworks is that they may have been written awhile ago. They cannot possibly account for all the ways they will be used.

This is a great example of how the default implementation of our framework left us open to this rate limiter bypass vulnerability.

How We Fixed It

As mentioned above, the first value in this header is only accurate in a completely trusted environment, and so our framework's default implementation is insecure since it does not account for untrusted values in that header.

This prompted us to restrict our rate limiting logic to prefer user ids instead of IP addresses, so that IP addresses are only used for unauthenticated API calls. We have very few unauthenticated API calls. More importantly, we discovered that our application framework blindly selected the first IP address from X-Forwarded-For as the source of truth.

We revamped this logic to be more intelligent about how these IP addresses were chosen, and similar to the Tomcat approach, we now grab the first valid IP address from the end. We intentionally extract values that we know come from trusted sources in our control.

This is another classic example of input validation. When it’s at the low-level networking layer like this it has the potential to go largely unnoticed.

Are You Safe?

Have you explicitly validated how your own applications handle X-Forwarded-For?

More importantly, you must validate it by approaching the problem as an attacker would. Inspect the features that you have which rely on this client IP. Rate limiters, audit logs, or geographical usage stats, and try sending in spoofed X-Forwarded-For addresses.

Do your applications use this spoofed value, or do they select the correct one added by your proxy with an accurate value?

Understanding gRPC Security: How StackHawk Keeps Your APIs Protected

Brian Erickson

As modern applications become more complex and distributed, gRPC is rapidly gaining traction as a powerful and efficient framework for building microservices and connecting various components across distributed computing platforms. But with all the exciting benefits gRPC brings to the table, it's essential to keep security top of mind. That's where StackHawk comes in, offering a robust solution to secure your gRPC services and APIs.

In this blog post, we'll dive into what makes gRPC unique, explore its common use cases, and compare it to other popular API technologies like OpenAPI and GraphQL. We'll also discuss the importance of testing gRPC services for security vulnerabilities and how StackHawk's dynamic application security testing (DAST) capabilities can help you ensure your gRPC APIs are both powerful and secure.

Join us as we navigate the exciting world of gRPC and discover how StackHawk can help you stay ahead of potential threats while building the next generation of API communication. And don't miss out on our special offer for production-level gRPC users who provide valuable feedback during our beta period!

What is gRPC?

gRPC is an open-source, high-performance framework that's gaining popularity for building microservices and distributed systems. It excels at service-to-service communication, as opposed to traditional APIs that often focus on service-to-client browser communication. Recognized for its speed and efficiency, gRPC enables seamless connections between mobile apps, backend services, and various components across distributed computing platforms.

How does gRPC differ from OpenAPI or GraphQL?

gRPC, OpenAPI, and GraphQL are all distinct technologies for building and consuming APIs, each with its strengths and ideal use cases.

gRPC utilizes the Protocol Buffers data serialization format and supports both synchronous and asynchronous communication. Ideal for building internal, microservices-based architectures, gRPC places a strong emphasis on performance and scalability, enabling efficient service-to-service communication.

OpenAPI (formerly known as Swagger) is an open-source framework for building and documenting RESTful APIs. It uses a JSON or YAML file to define the API's endpoints, parameters, and responses, making it particularly suitable for creating and documenting public-facing APIs. OpenAPI boasts a large ecosystem of tools for generating code, documentation, and testing, fostering ease of use and collaboration.

GraphQL is a query language and runtime designed for constructing flexible, high-performance APIs. Unlike RESTful APIs, which have fixed endpoints and response structures, GraphQL empowers clients to request precisely the data they need and nothing more, all from a single endpoint. This approach leads to more efficient data retrieval and an improved developer experience, making GraphQL a popular choice for building public-facing APIs.

Benefits of gRPC

gRPC boasts several advantages, such as:

High performance due to serialized protocol buffers
Cross-platform support for various programming languages
Language-independence, with generated code for client-server communication
Streamlined development for complex distributed systems
Interoperability with HTTP/2-based systems
Secure communication using Transport Layer Security (TLS)
Scalability with built-in load balancing

Common gRPC use cases

Microservices architectures: gRPC streamlines inter-service communication in modern, distributed applications. With efficient data serialization using Protocol Buffers, support for multiple programming languages, and built-in load balancing, gRPC is ideal for building scalable and maintainable microservices-based applications.
Real-time applications: gRPC's support for bi-directional streaming enables the rapid exchange of data between client and server, making it perfect for real-time applications. This capability is invaluable for chat apps, live notifications, real-time data streaming, online gaming, and other use cases where low latency and continuous data exchange are crucial.
Mobile apps: Due to limited bandwidth and resources on mobile devices, gRPC's lightweight and efficient communication is a significant advantage. Its compact binary serialization format, Protocol Buffers, reduces the payload size, resulting in faster data transfer and reduced network usage. This makes gRPC an excellent choice for mobile applications where performance and responsiveness are essential.

Despite the many benefits and diverse use cases gRPC supports, it's essential not to overlook the importance of security testing for gRPC (and all your APIs!).

Why test gRPC Services?

While gRPC communication typically happens inside the firewall, it's crucial to maintain strict security practices to protect your APIs. Securing every part of your system ensures a more comprehensive approach to overall security.

gRPC services, like REST, SOAP and GraphQL APIs, are susceptible to attacks from the OWASP Top 10, so don't assume they're immune. In particular, gRPC applications can be exploited through:

Broken Access Control
Cryptographic Failures
Injection
Insecure Design
Security Misconfiguration
Sensitive Data Exposure
Insecure Deserialization

Secure your gRPC services with StackHawk

Traditional DAST tools may not support gRPC, but StackHawk has you covered. It's designed to work with gRPC services over HTTP/2 using protocol buffers to generate requests and parse responses. This allows StackHawk to effectively target and check gRPC application endpoints, identifying potential security issues.

With StackHawk, you can leverage Custom Test Data and Custom Test Scripting to conduct comprehensive security testing on your gRPC APIs. Custom Test Data allows you to specify input values for your gRPC API requests, which ensures that your security testing covers the wide range of potential data interactions your application might encounter. This helps identify vulnerabilities that could arise due to unexpected or malicious input.

Custom Test Scripting enables you to create tailor-made test scenarios for your gRPC APIs. You can write scripts that define specific sequences of requests and responses, mimicking real-world user interactions and potential attack patterns. By customizing your testing approach, you can better identify security vulnerabilities and edge cases unique to your application's architecture and business logic.

Combining Custom Test Data and Custom Test Scripting with StackHawk's dynamic application security testing capabilities, you can thoroughly assess the security of your gRPC APIs, ensuring that they are robust and resilient against potential threats.

Have a gRPC Application in Production? Earn swag for your feedback!

If you're already using gRPC in production, we'd love to hear from you. Reach out to give us your feedback. During the beta period, we're offering a StackHawk Swag Pack (or $100 Gift Card) to those who test production-level gRPC applications as a thank you for your valuable input!

To get started, scan your gRPC application using our getting started guide and reach out to product@stackhawk.com with your feedback!

Brian Erickson is Sr. Product Manager at StackHawk

Read more:

Automate Security in CI/CD with StackHawk and Azure DevOps

Alberto Fidalgo

In the world of software development, tools that can help proactively identify security threats and improve automation are at the top of IT leaders’ wish lists in 2023. Azure Pipelines and Azure Boards are DevOps tools that can help you manage projects and automate the process of testing, building, and deploying your software to the cloud. Integrating StackHawk with these two tools makes it easier for development teams to ensure their software is secure before it moves to production.

Azure Pipelines

Azure Pipelines is a CI/CD tool that allows teams to build, test, and deploy their applications. With the StackHawk integration, you can add application security testing to your pipeline, allowing you to find and fix security issues before they reach your end users. Our integration with Azure Pipelines is easy to set up in just a few steps.

First, you'll need to install the StackHawk Azure Extension to your Azure DevOps Organization. You will also need a StackHawk account, StackHawk API Key, and a Stackhawk application ID to run HawkScan tasks. The StackHawk Azure extension consists of two tasks: HawkScanInstall and HawkScanRun.

HawkScanInstall installs the user's preferred version of HawkScan or defaults to the latest version available.
HawkScanRun runs the installed version of HawkScan.

Pretty straightforward, right?

Our primary goal is to provide teams with new Azure Pipelines tasks they can use in their CI/CD builds to scan for vulnerabilities in running applications. The StackHawk Azure extension works with almost any Azure Agent right out of the box, whether Windows-based or Linux based, without needing to tweak any settings.

Read the docs to learn more about the StackHawk and Azure Pipelines integration.

Azure Boards

Azure Boards, on the other hand, is a project management tool that allows teams to track work items, bugs, and other project-related tasks. With the StackHawk integration, you can create a new issue in Azure Boards whenever a security issue is discovered, making it easier for your team to track and prioritize security issues alongside other development tasks.

To set up the StackHawk integration with Azure Boards, navigate to the Azure DevOps Boards Integration page in StackHawk and provide your username and personal access token. This will allow StackHawk to send notifications to your Azure Boards project whenever a new security issue is found. Once the installation is verified, you can send a finding to Azure Boards by creating a work item and associating it with a StackHawk scanner finding.

Read the docs to learn more about the StackHawk and Azure Boards integration.

10 Application Security Best Practices to Adopt Today

StackHawk

Applications are the backbone and most valuable asset of almost every business that exists today. Being as valuable and crucial to business operations as they are, web applications tend to also attract attackers. Because of this, web application security has become a prime focus for developers and their enterprises. It’s never too early or too late to adopt best practices for application security but neglecting to implement them will almost always lead to disaster. As is said about many things, “it’s not if, it’s when”. Every application will likely be put to the test by attackers at some point so it pays to be prepared.

In this post, we'll look into 10 popular application security best practices. Some of these apply directly to the code within your web application itself, the infrastructure it is deployed on, and also the potential human factors which lead to security vulnerabilities. Whether you're just starting with security and want to know what it entails, or you’re a veteran developer looking for a refresher, you’ve come to the right place. Let’s dig deep and first take a look at several important principles of application security.

What Are the Principles of Application Security?

Principle of Least Privileges

The principle of least privileges focuses on controlling an entity's access to resources. This principle states that any entity should be given only the least amount of privileges required per business needs. By limiting access, you’re reducing the risk of intentional or accidental harm. With this principle, it is an important part of a security audit to check that entities have the correct access to certain data and system privileges.

Learn how StackHawk supports this principle with Teams and Roles.

Security by Obscurity

Obscurity means the state of being unknown. You can think of security by obscurity as the next level of security after authentication and encryption. With authentication and encryption, you’re making sure that only authorized users are allowed to access the system and that data is encrypted and kept out of the hands of an attacker. However, the attackers will still know that these mechanisms are in place and will likely try to break or bypass them to gain access to the system.

Security by obscurity is the practice of hiding data, mechanisms, or systems to keep them away from attackers’ eyes. The idea is that if the attackers don’t know that there’s something present, then won’t try to actively attack it. It’s important to layer this approach with the other principles and not solely rely on it.

Failing Securely

This principle is about preparing for the worst. No matter how much security you implement, your systems will never be 100% secure. With the security landscape constantly changing, and with the fundamental reality that sometimes technology fails, there's always a chance that things will fail. This principle is about damage control and minimizing the impact of potential security failures and breaches—aka managing risk at an acceptable level. Failing securely is about planning for failures so that you contain the impact of the failure and that the failure doesn't open doors for attackers to breach your application or cause more damage.

Minimizing the Attack Surface

Modern applications are complex and made up of several components and features. This increase in complexity also increases the attack surface. Modern software usually uses third-party extensions and dependencies, distributed services, and many other components which may be outside of your direct control. This provides more ways for attackers to gain access to your web application and data. It also makes it difficult for you to strengthen security against these factors. Minimizing the attack surface will leave fewer opportunities for attackers to take advantage of a vulnerability.

Application Security Best Practices

Now that we've reviewed these crucial principles of application security, let's look into application security best practices. Each best practice below makes up a piece of a holistic approach to application security. It’s important to remember that the list below is not exhaustive, many other best practices could be included in your security strategy, and any single best practice is not sufficient to protect against all threats. Combining the techniques below is the best way to protect your applications.

Use Encryption

Application security is incomplete without encryption. Without encryption, data at rest and in transit can easily be accessed by potential attackers. Encrypting data is an initial and perhaps the most crucial practice you should implement on this list. Every application deals with some kind of sensitive data, and encryption helps you keep this data out of the hands of unauthorized personnel. As important as using encryption is, using strong encryption mechanisms is equally important. If you don't use encryption, attackers can easily take advantage of access to your data storage systems. Attackers can also use attacks, such as the Man-in-the-Middle technique, to steal sensitive information. This is why, as mentioned earlier, your encryption strategy should focus on both data in transit and data at rest.

As a first step, evaluate your application and understand what components or areas of the application need encryption. Once you have established this, you'll need to plan any changes to the application to cater to the needed encryption. Many languages and frameworks can easily integrate encryption best practices directly into them with minimal work. Then, eventually, you can make the shift from an insufficient or non-existent encryption implementation to a sufficient encryption strategy.

Bring in Security Early

As companies have started to focus more on app security, the practice of bringing in security during the early stages of development has become quite popular. DevSecOps is a popular practice that has gained a lot of steam in the last few years. This approach to bringing security influence early into the development lifecycle is allowing application security to “shift left”. When you start focusing on security earlier, you make everyone responsible for it. Not just the security teams, but the developers and testers also take a security-focused approach when building and testing an application. With this, you will be able to identify and remediate security weaknesses as they are introduced into the application before they make it to production. This will strengthen the application's security at its core.

When you don't focus on app security early in the development lifecycle and leave it until after the application is developed, it's more expensive to fix weaknesses identified later. For instance, if a major vulnerability is found and is baked into multiple areas of the code, a major refactor will need to take place. Generally, this means that the code will then need to go through deployment and QA release processes again too. This increases the cost of a project and the timeline for the release.

Most importantly, if you fail to identify or fix these weaknesses in time and the application is pushed into production, the application remains insecure and gives an upper hand to attackers. DevSecOps can reduce the likelihood of these scenarios taking place. Bringing in a DevSecOps methodology does require a cultural shift, so if you plan on bringing DevSecOps to your organization, you have to start by changing the mindset of your teams and training them accordingly.

Risk Assessment

Risk assessment is the process of identifying and evaluating risks. Understanding security risk is important because it helps you interpret where you're at and what security measures are appropriate for you. Performing risk assessments and acting on the results helps you avoid breaches and regulatory issues and reduces long-term costs. Many enterprises, especially those that are heavily regulated, have risk assessments built into their software development lifecycle by default. Usually, this involves having a rating system to classify the risk associated with each application based on specific factors. These factors may include the impact of data loss, network or application outages, or a data breach.

Risk assessment gives you a larger picture of your application's security. Without it, you might not be able to identify all areas where you need to implement or enhance security. Risk assessment starts with identifying risks and evaluating them. Then, you can begin to design and apply improvements to decrease the risk within the application. Finally, you should test your improved app to make sure that it has improved in the areas outlined for improvement. Risk assessment is an ongoing process that should be conducted as part of the duties of application design, build, and ownership.

Logging

A lot of intelligence can come from data produced by your applications and application logs are a great source of data to evaluate and enhance application security. As part of this, you need to ensure that proper logging is implemented for your application to truly get a better understanding of what's happening behind the scenes.

Logs can be used for proactive and reactive security. You can identify how attackers are trying to break into the security of your application and work on improving security to avoid a breach. Logs play a significant role in incident response if attackers manage a breach. Without proper logging, you don't have visibility into your application and its infrastructure. A great way to use logs for security is to deploy a log monitoring tool that can look for specific patterns and scenarios and alert teams of potential security threats.

You need to be very tactful in how you plan and implement logging for your applications. Too much or too little is not good. Too little logging will not allow you to see how your application is truly being used. Too much could clog up the log stream and be hard to parse through. As well, logging too much data could expose data that could cause issues, such as logging login credentials or sensitive data, if an attacker were to gain access to the logs. Therefore, your logging strategy is an extremely important part of the implementation. Before you start implementing logging systems, try to understand what needs to be logged and how long your log retention period should be. After that, go about designing and implementing logging.

Real-time Monitoring and Protection

A couple of minutes, or even seconds in some cases, is enough to do a lot of damage when an application is breached. You might have implemented extremely sophisticated and intelligent security systems, but if they don't act on time, they're no help when attackers strike. We live in an age where only real-time reactivity is fast enough. Real-time monitoring and protection help you act in time and manage incidents in the moments they occur either by notifying the appropriate parties or through automation. However, it’s important to note that not all areas of an application necessarily need this real-time monitoring and protection. The best approach is to start by identifying which areas need real-time monitoring and protection, the potential tools that offer real-time monitoring and protection, and, lastly, applying the capabilities of the tool to fit the needs of your application.

Vulnerability and Patch Management

Vulnerability management is the process of identifying and prioritizing vulnerabilities. Patch management is the process of planning and applying patches to the software and infrastructure that your application uses. Both of these processes are important to stay up to date with the latest fixes and avoid a potential breach.

As applications have become more complex, security vulnerability and patch management is not an easy task anymore. There are generally a wide variety of languages, frameworks, third-party dependencies, and infrastructure products that are used to create modern web apps. Based on each of these components, you need to track and apply fixes and mitigations in time, without impacting “business-as-usual” processes. Not patching a security issue in time leaves room for attackers to exploit them. One way to approach this is by identifying all components that need management, putting policies in place for vulnerability and patch management, and defining processes for handling the work involved. Automation can be of great help in this process since some systems can automatically manage and install the latest patches.

When it comes to cloud applications, some managed services where an app is hosted will automatically have the latest patches applied. This is one aspect of cloud application security that can give it a leg up on traditional on-premise vulnerability and patch management. This is part of the allure of shifting applications to the cloud.

Security Training

One of the weakest links in security is humans. In any organization, there are a wide array of employees with various knowledge of security best practices. This leaves a potential gap for attackers who can use tactics, such as social engineering, to gain access to a system via an unknowing employee. For example, a malicious link could be used in an email to phish for access credentials.

Security training is important for two reasons. First, training and awareness result in employees building secure applications and implementing secure practices as they manage and deploy applications. Second, it avoids breaches through attacks involving humans, such as social engineering attacks. Proper training helps employees think in terms of security, which will be reflected in their tasks and boost the application's security.

Use a Cybersecurity Framework

Cybersecurity frameworks provide guidelines to improve the security of different types of applications and infrastructure. There are several frameworks out there, such as NIST or MITRE, that you can apply to your applications and use for enhancing security. You can use these frameworks to analyze your current security implementations to see if there's any aspect you're lacking. Alternatively, if no security is in place yet, you can use them as a blueprint to build your security design.

Although using cybersecurity frameworks is mostly up to one's preference, you might have to adhere to one or more of these frameworks for regulatory purposes. Certain industries require that certain standards or frameworks are adhered to. Failing to adhere to the expected standards or framework might result in large fines and other penalties. If you are in such an industry, the first step is to go through the regulations and see what frameworks you must adhere to. After researching and defining what your security strategy must look like, you can then implement the appropriate security mechanisms.

Application Security Testing

Once you've applied all security measures you can, it's time to see the outcome and test the security of the application. Application security testing plays a very important role as it helps you evaluate your security implementations and identify anything you might have missed. Without testing, you can't be sure about the impact of your security measures. There are plenty of ways that application security testing can be applied to developed software.

Of course, one type of security testing we can think to implement is the manual approach of penetration testing. On top of penetration testing your systems, you also may look to automate testing as well. Many different security tools exist for this, most of which can be implemented at the onset of application development.

Two types of application security testing tools we will look at here are:

Static Application Security Testing (SAST)
Dynamic Application Security Testing (DAST)

SAST involves scanning the application code to identify security loopholes in code implementation, potentially including vulnerable dependencies or components of the application. The great part about SAST is that it doesn't need the application to be running. This means it can be applied as soon as the first line of code is written.

DAST, on the other hand, tests the application while it's running. It focuses on interacting with the application and checking to see how it responds to actions. Unlike SAST, DAST tools require that the application is in a runnable state since it executes its testing procedures against the live, running application. Both tools are extremely complimentary to each other and are a great base for an automated testing strategy.

Depending on your application, you have the choice to choose a tool that works best for you. A great DAST tool you might want to check out StackHawk's DAST tool since it is extremely easy to configure and set up. It's a complete solution that tests your running applications, services, and APIs for security vulnerabilities. It integrates into engineers' workflow by integrating directly into the CI/CD pipeline, giving them quick and automated feedback loops to find, fix, and triage. This also gives security teams complete visibility into what is happening and control over what to prioritize and fix.

Conduct Bug Bounty Programs

Bug bounty programs are an extension of security testing. Depending on the tools you use and your team's knowledge, you might be limited in what weaknesses you discover in the application. Also, prior knowledge of what the application is and how it functions might narrow your view while testing. A bug bounty program is a great way to get an outsider's view of your application security.

A bug bounty program generally offers a financial reward to people who find and report bugs in an application. These programs have become a mainstay for many companies including Yahoo, Cisco, Snapchat, and many others. Bug bounty programs are a great way to include the security community and ethical hackers in the process of making your applications more secure.

Check out StackHawk's ZAP bounty program.

Conclusion

Application security is a must in this era, and it's good that companies are focusing on it at an increasing rate. Building a highly secure web application is not an easy task, especially when modern web applications have become so complex. You need good planning, design, and execution to get it right. In this post, we went through some of the most popular application security best practices to build a baseline for your application’s security. Depending on your application and business needs, you might need to incorporate more security practices than what we have covered here. At a minimum, applying each security best practice mentioned in this article is a good place to start.

One of the game-changing factors in application security is the set of tools you use. StackHawk's DAST is one such tool that can change the way you look at application testing and API security. Easily integrated into your CI/CD pipeline, StackHawk allows for repeatable and automated testing to ensure the security of your application. If you're interested in knowing more about this tool, check out the demo to see exactly how powerful and easy the platform is to use.

10 Web Application Security Threats and How to Mitigate Them

StackHawk

Web application security is crucial to ensuring the safety and security of online systems and their users. As more and more daily activities and transactions move online, the importance of securing web applications becomes increasingly clear. Daily reports of breaches and always-changing security threats mean that security is a top priority for every organization.

In this article, we'll explore ten common web application security threats, the consequences of these threats, how web applications are vulnerable to them, and how to mitigate them.

10 Web Application Security Threats

Here are the ten common web application security threats we will cover in this article:

SQL injection
Cross-site scripting (XSS)
Cross-site request forgery (CSRF)
Insecure direct object references
Remote code execution
Insufficient logging and monitoring
Insecure cryptographic storage
Failure to restrict URL access
Cross-origin resource sharing (CORS) misconfiguration
Using components with known vulnerabilities

1. SQL Injection

A SQL injection attack is executed when an attacker injects malicious code into an application's database through user input fields. These types of attacks can accomplish many different things. Two of the most common outcomes include allowing the attacker to gain unauthorized access to sensitive data stored in the database. Depending on what data the database is storing, the attack could get access to passwords, financial information, and personal data. The second outcome could be the manipulation or deletion of data. For instance, a user may be able to execute a DROP TABLE or DROP DATABASE command.

You can mitigate this with the following steps:

Validate user input.
Use output encoding, which involves converting special characters such as < and > into their HTML entity equivalents, to prevent them from being interpreted as HTML code.
Use prepared statements, parameterized queries, or stored procedures instead of dynamic SQL whenever possible.

Most languages and frameworks have recommended ways of handling form input. By combing frontend and backend standards to prevent SQL injection from happening, your application can increase its security against this type of threat.

2. Cross-Site Scripting (XSS)

Cross-site scripting (XSS) attacks involve injecting malicious code or a malicious script into a website. The website then executes the script, allowing the attacker to steal sensitive user data, like session tokens and cookies, or perform other actions.

There are two main types of XSS attacks: reflective and stored. Reflective XSS attacks involve injecting malicious code into a website that is immediately executed. Stored XSS attacks involve injecting malicious code into a website that is stored and executed at a later time.

If successful, a cross-site scripting attack can result in the theft of user session IDs, website defacement, and redirection to malicious sites, thereby enabling phishing attacks.

You can mitigate this with the following steps:

Validate user input.
Use output encoding techniques.
Use auto-sanitization libraries such as OWASP AntiSamy.
Implement a content security policy.

Similar to the recommendation for SQL injection, using modern web frameworks generally tends to steer developers towards secure coding practices to avoid XSS and similar attacks.

3. Cross-Site Request Forgery (CSRF)

Cross-site request forgery (CSRF) is a type of attack that involves tricking a victim into performing an action on a website without their knowledge. This can be done by injecting a malicious link or form into a website that the victim is already authenticated on.

When the victim clicks the link or submits the form, the action is performed on their behalf, potentially leading to data loss or unauthorized access.

You can mitigate this with the following steps:

Leverage CSRF protections already built into the framework you are using, if applicable.
Use CSRF tokens. These are unique, randomized values associated with a user's session and are included in forms and links to verify the authenticity of the request.
Use SameSite cookies. These are a type of cookie that is only sent with requests to the same origin as the cookie's creation. This can help prevent attackers from being able to send requests on behalf of a victim, as they would not have access to the victim's SameSite cookies.

4. Insecure Direct Object References (IDOR)

Insecure Direct Object References, or IDOR, occur when an application exposes direct object references, such as URLs or database keys, that allow attackers to access restricted data by manipulating these references.

For example, an application may allow users to access their account information by entering their account number in a URL, such as "www.example.com/account/123". An attacker could potentially access other users' account information by changing the account number in the URL.

You can mitigate this with the following steps:

Implement proper access controls and session management. This involves setting up mechanisms to ensure that only authorized users have access to certain resources or data. The OWASP cheat sheets on authorization and authentication can be helpful resources for reviewing best practices in these areas.
Validate user input. To help prevent attackers from manipulating direct object references to access-restricted data, ensure that user input is the correct type, length, and format.
Avoid using predictable references. Instead, consider using globally unique identifiers (GUIDs) to prevent attackers from guessing the direct object references they need to access restricted data.

As noted in the mitigation steps above, IDOR-based vulnerabilities don’t occur on their own. These vulnerabilities must be coupled with other vulnerabilities to become an effective attack vector.

5. Remote Code Execution (RCE)

Remote Code Execution (RCE) attacks allow attackers to execute arbitrary code on a server, potentially leading to full system compromise and unauthorized access to sensitive data.

RCE attacks can occur through a variety of means, such as exploiting vulnerabilities in code libraries or injecting malicious code through user input fields.

A successful RCE attack can have several consequences. These include Denial of Service (DoS) attacks, exposure of sensitive data, illicit cryptocurrency mining, and execution of malware. In some cases, a successful RCE attack can even give full control over the compromised machine to the attacker.

You can mitigate this with the following steps:

Sanitize user input.
Implement secure memory management. RCE attackers can potentially take advantage of memory management flaws such as buffer overflows. Conducting regular security vulnerability scans on your applications can help you identify buffer overflow and memory-related vulnerabilities that an attacker could exploit.
Always keep your operating system and your third-party software up to date to ensure that you have the latest security patches.
Limit the attacker's ability to move through a network y implementing network segmentation, access management, and a zero-trust security strategy.

RCE attacks have been a major source of breaches in the last few years, many leading to worldwide security emergencies. One that many people will remember is the Log4j fiasco discovered in 2021 where multiple RCE vulnerabilities were discovered in Log4j. These RCE vulnerabilities allowed attackers to exploit vulnerable applications to execute Cryptojacking attacks and other malware on compromised servers.

6. Insufficient Logging and Monitoring

Insufficient logging and monitoring refer to a lack of proper logging and monitoring processes in place to detect and respond to security threats. This can allow attackers to go unnoticed and continue to compromise the system, potentially leading to data loss and financial loss.

It’s also important to be aware of what is being logged. If secure information, such as credit card numbers or passwords, are being written to logs, attackers who gain access to the logs could use this information maliciously. Fraudulent credit card charges or unauthorized access to a system could be easily executed.

You can mitigate this with the following steps:

Enable logging for key events and actions in your application and monitor logs regularly.
Use log analysis tools. These can help automate the process of reviewing logs and identify potential security issues or anomalies more quickly and efficiently.
Set up alerting systems to notify administrators of any potential security issues in real time, allowing them to respond more quickly to potential threats.
Ensure that sensitive information is either not included in logs or is properly masked.

7. Insecure Cryptographic Storage

Insecure cryptographic storage refers to the improper handling of cryptographic keys, such as storing them in plain text or using weak keys. This can allow attackers to gain access to sensitive data through compromised cryptographic keys.

You can mitigate this with the following steps:

Use strong cryptographic algorithms, such as AES or RSA, to secure stored data.
Implement key management best practices, such as regularly rotating keys and securely storing them, to help prevent unauthorized access to encrypted data.
Use secure storage solutions, such as hardware security modules or encrypted storage devices, to help further protect encrypted data.

One suggestion is also to audit the data that you need to store in an encrypted state. The best way to protect data is to simply not store it at all. If sensitive data is being stored without need, it may be best to forego the storage of this data to lessen the data that potential attackers have access to.

8. Failure to Restrict URL Access / Broken Access Control

Failure to restrict URL access refers to a lack of proper access controls that allow unauthorized users to access restricted pages and resources. This can allow attackers to access sensitive data and potentially compromise the system.

This security threat is mostly similar and related to the IDOR vulnerabilities we discussed earlier. The core differentiating factor between the two is that IDOR tends to give the attacker access to information in the database, while failure to restrict URL access allows the attacker access to special functions and features that should not be available to any typical user.

You can mitigate this with the following steps:

Implement proper access controls by setting up authentication and authorization processes to ensure that only authorized users have access to certain resources or functions.
Use role-based authorization. The enforcement mechanism should deny all access by default, requiring explicit grants to specific users and roles for access to every page.
Implement adequate authorization measures at relevant stages of user web app use.

Many routing libraries and routing mechanisms built into modern web frameworks tend to protect against this by default. By making sure that the application routing is set up correctly, these types of vulnerabilities can be completely avoided.

9. Cross-Origin Resource Sharing (CORS) Misconfiguration

Cross-Origin Resource Sharing (CORS) is a security feature that allows a web server to specify which domains are allowed to access its resources. However, if CORS is misconfigured, it can allow attackers to access restricted resources from a different origin. This could potentially expose data through services that can be used without authorization.

You can mitigate this with the following steps:

Properly configure CORS headers.
Use CORS libraries that provide an easy-to-use interface for configuring CORS headers to help you configure CORS properly.

Many server-side frameworks and platforms can aid developers in properly configuring CORS for their services. Developers should be aware of how CORS can be configured in the framework of their choosing. One common reason for CORS security misconfiguration is that when developers are creating applications locally they will set an entirely open CORS policy for easier development. Ensuring that these policies do not get checked into production code is crucial.

10. Using Components with Known Vulnerabilities

Using components with known vulnerabilities refers to the use of outdated code libraries, frameworks, or other components with known vulnerabilities.

Many websites today are built using complex components, which can make it difficult for development teams to understand their internal workings. This can create potential vulnerabilities if a component contains known security issues that are not properly addressed.

You can mitigate this with the following steps:

Keep track of component versions. You can address any vulnerabilities by regularly checking for updates and staying up to date with the latest versions of components.
Use security scanners to help you identify known vulnerabilities in components and alert developers to potential issues.

Using tools like Dependabot can help keep your dependencies up to date automatically. By using scanning tools and automation, keeping dependencies secure and up-to-date is easy to do as part of the development process.

What Is the Biggest Security Threat to a Web Application?

It's difficult to determine the single biggest threat to a web application. This is because it depends on the specific web application and its unique vulnerabilities.

However, the most common application security threats according to the OWASP Top 10 are broken access control, cryptographic failures, and injection (including SQL injection and cross-site scripting). By using the latest tools for security scanning and monitoring, as well as the latest secure coding practices, developers and their organizations can limit their exposure.

Conclusion

Web applications are an integral part of modern life, and as such, they're a common target for attackers. By understanding common security threats and implementing proper mitigation techniques, web application developers and administrators can help protect their systems and users. To assist with this process, consider using a security platform like StackHawk to automate and improve your application security testing.

With StackHawk, developers can add Dynamic Application Security Testing directly into their CI/CD pipelines. StackHawk scans the running application for vulnerabilities that are outlined in the OWASP Top 10 and more. Developers are then able to view reports for each test that is executed, uncover vulnerabilities, and be guided on fixes. The best part: all of this can happen before the application hits production. To see the benefits of StackHawk for yourself, sign up today for a free trial.

Learn more

Read on to see how StackHawk’s CSO, Scott Gerlach talks about “Shift Left” being more than just a buzzword here.
Check out why Omdia’s On the Radar report highlights StackHawk as an “interesting alternative to most other DAST tools” here.
Getting started with StackHawk? Check out Advice and Answers from the amazing StackHawk team here.

Get Your Entire Flock Secured: StackHawk Launches Team-Sized Support

Brian Erickson

Say hello to seamless security for large and growing companies!

At StackHawk, we believe that security is not just about scanning your applications and APIs, it's about empowering development teams to be the guardians of their code. And that's why we're excited to announce support for Teams, making it easier for organizations to bring their entire crew into the fold. With Teams, you can now organize your applications based on products and services, giving team members the focus they need to secure what matters most.

Plus, account administrators can breathe easy knowing that team members can only access what they need, without the risk of accidental mishaps.

New Role: Member

Adding new users to your team can be a challenge, especially when you want to make sure your account stays organized and you don’t lose past scan results or application configurations. By giving new users the Member role, you can control which applications they have access to and ensure account-level settings such as billing and integrations are not modified. This feature makes the process of adding new members to your team simple and stress-free, allowing you to focus on your work with peace of mind.

Teams provides a robust foundation for managing access rights and visibility for developers. It enables me to more precisely control what developers can see and do within StackHawk, elevating our security and productivity. - Kerry @ Healthcare Bluebook

Organizing Applications around Teams

One of the key features of Teams is the ability to organize applications in a way that fits your organization's needs. Whether you're grouping services for a particular product, APIs for a specific team, or applications for a particular department, Teams provides the flexibility to adapt to your organization's workflow. With Teams, you can easily focus on a set of specific applications or scan results using quick filters, which is especially helpful for organizations with many applications to manage. On top of that, by assigning users the Member role to specific Teams, you can ensure that they can only access the applications they need to do their job, making your organization more secure and efficient.

The ability to split applications into smaller, dedicated teams has been a game-changer for me. It allows me to easily assign developers to their respective projects, fostering greater efficiency and productivity across our portfolio of two - soon to be three - products. - Todd @ ICD Technology

Getting Started with Teams

To start setting up Teams for your Organization, as an Owner or Admin, navigate to the User Management area in Settings. There you can invite users to your account, update roles and create new Teams.

Invite Users and Assign Roles

Before you create new Teams we suggest you update the Roles for your existing Users. To reap the full benefits of Teams we recommend assigning Users that will be added to Teams the Member role. This will ensure they only have access to Applications assigned to Teams they are added to. More specifics on how roles work in StackHawk can be found in our documentation.

Create your first Team

From the Teams settings screen, you can now create a Team by adding Users and Applications. Users added to a Team will have full access to Applications assigned to the Team and Users with the Member role will only be able to see Applications on Teams they are assigned to. Check out our documentation for more information on setting up Teams.

The Teams feature is now available for all StackHawk customers on our Enterprise plan, which is part of every 14-day trial so sign up today!

Brian Erickson is Sr. Product Manager at StackHawk

📺 Watch a Quick Demo

[Video]

Learn more:

StackHawk ❤️ APIs

Dana White

On this Valentine’s day, make sure to pop open a bottle of champagne and drink it with the one you love. And by the one you love, I mean your API. And by drink champagne, I mean scan every pull request with HawkScan to make sure it is free of any vulnerabilities.

At StackHawk, we love APIs:, GraphQL, SOAP and our own REST API that supports our platform. And we make sure to regularly scan them all.

StackHawk loves REST and GraphQL and SOAP

For our true blue and stalwart suitor (the simple API backed by a DB setup) we can two-step with them at the local sock hop (what’s a two-step and sock hop? who are these references even intended for?). Scanning a GraphQL app with HawkScan in Kubernetes is a snap. Just throw your sweetheart (HawkScan) in your sidecar (your sidecar is a Kubernetes sidecar but also works as a metaphor) and drive (probably to the local malt shop or something).

Here’s an example of our manifest.

We’ve loaded our stackhawk.yml and custom authentication scripts in our /conf directory that we’ve volume mounted onto our pod with a config map. We use this setup against GraphQL, SOAP and REST.

We test each release of HawkScan against our vulny apps (look them up here and pick your poison https://github.com/kaakaww) to ensure it catches all the vulnerabilities (security exploit vulnerabilities not ones related to emotional maturity).

But what happens when your application doesn't look like a single container and looks more like this.

On top of that, you made a great choice to run gRPC, but you can't HawkScan gRPC.

We look like this too

To avoid corrupting staging and production data, we create an environment to test against a PR, as ephemeral as a kiss blown in the wind. Our traditional REST API is backed by microservices with gRPC communication. So to get meaningful scan results from our scanner we need all those microservices and their supporting databases (hopefully with some data) running.

We heart Docker

On each PR, we launch our API and every one of its dependencies in Docker containers and scan it. And if you’re using GitHub Actions you can throw HawkScan Action into your pipeline…look at how cute she is: https://github.com/stackhawk/hawkscan-action. Just a few lines of configurations in your workflow brings it in:

- name: RunHawkScan id: run-hawkscan uses: stackhawk/hawkscan-action@main with: apiKey: ${{secrets.HAWK_API_KEY}}

So we spin up each of our services in their own Docker container and our API and scan them with our HawkScanner. But that’s a lot of containers…I don’t know about you but the majority of our gRPC services are backed by databases. So we’re spinning up at least two containers for each service and that’s a lot of containers…well at least 2 times the amount of containers as before.

But we’ve had our eye on Kubernetes, he’s cute

We could just as easily spin up a bunch of pods in Kubernetes with all their dependencies and launch HawkScan as a job or pod to scan the service.

This feels like scanning a monolith. Don’t we love microservices and tiny testing and shifting left? I want to get back to our true blue suitor.

Our Dance Card is Not Full

But wouldn’t it just be easier and more in line with engineering best practices to scan each microservice? Yeah, we see you and we’re here for you. HawkScan is starting a beta program for scanning gRPC services, so now you can stand up each microservice on its own and scan directly, making gRPC a first-class citizen like REST, SOAP and GraphQL.

So, if you heart gRPC like we do, enroll in our gRPC scanning beta and we can all go off holding hands and skipping through the tulips.

We heart you (sign up for our gRPC beta)

Roses are red Violets are blue Our API is secure How bout you(rs)?

Dana White is Senior Software Engineer at StackHawk

Read more

Sign up for a free trial of StackHawk today
Watch a demo
Get Started (Documentation)

Web Application Security Checklist: 10 Improvements

StackHawk

The importance of security in web applications can’t be understated. In today's digital age, web applications play a central role in our personal and professional lives. These applications are an integral part of our day-to-day interactions with the world, for better or for worse. One of the biggest concerns for most people and organizations is how these applications are storing and processing our most sensitive data. This data includes financial data, personal details, and other confidential information that users expect to be secure. As a result, web applications must remain secure and free from vulnerabilities that attackers could exploit.

In this article, we will discuss the key considerations for securing a web application. To make it as targeted as possible, we will provide a checklist of ten improvements that can help ensure the security of your web application. By following these best practices and taking a proactive approach to web application security, you can protect your users' data and ensure the integrity of your web applications.

Web Application Security Checklist

Securing a web app requires the regular review and improvement of existing security measures. Although web security and vulnerabilities are constantly changing, the practices below are timeless and should always be implemented and applied. Here is a list of things to check when building and securing your web apps. In each point, we also are sure to mention how to implement each suggestion and which vulnerabilities are addressed by implementing it. With that, let's get started.

1. Input Validation

Our first security measure to implement is input validation. By sanitizing and validating user input, you can prevent injection attacks and cross-site scripting. These types of vulnerabilities allow attackers to execute arbitrary code and potentially access sensitive data. These types of attacks can be easily executed, however, they can also be easily stopped.

The best way to ensure input validation is cohesive is by implementing measures on the front end and the back end (server) of the application. If you are only able to implement it in a single place, always make sure that the backend input is validated and sanitized. Sanitizing user input involves removing potentially harmful characters or data from user input. Validating user input involves ensuring that the input meets certain criteria, such as being in the correct format or within a certain range.

Many frameworks and languages have tools in place that allow users to easily implement this in their code. For instance, if you are building query strings in your code by simply taking user input and pushing it into a query, this is extremely unsafe and could easily leave you vulnerable to a SQL injection attack. A better way may be to use a parameterized query, call a stored procedure, or by using an ORM solution to access and manipulate data.

2. Authentication and Access Control

Making sure that your application can only be accessed by authorized users is the second improvement on our list. By making sure that users are supposed to have access, we can exponentially cut down the number of exploits available to potential hackers. To go further, you may also want to implement access control so that users only have access to the data and services that they require, nothing more.

As part of the authentication implementation, implementing secure password storage is crucial. If passwords are easily attained by attackers, entry into the application is no longer a barrier. To further protect users and your application, multi-factor authentication should also be included in your authentication measure. Multi-factor authentication, or MFA, helps prevent unauthorized access to your web application by enforcing another step in the authentication process. A common way of doing this is to send a login code to a trusted device via SMS or email to make sure that the user is fully authenticated.

The two best ways to achieve great authentication and access control standards are:

Using secure hashing algorithms for storing passwords
Requiring regular password updates
Implementing authentication methods, like two-factor (2FA) and biometric authentication

Many different services and frameworks include mechanisms for ensuring that authentication, authorization, and access control standards can easily be implemented.

3. Use of HTTPS and TLS encryption

Our next suggestion is to ensure that your applications are secured with the use of HTTPS and TLS encryption. This approach to web application access has become a standard even for apps that are not dealing with secure data or transactions. Many customers expect that all sites will be secure, especially the ones that are handling sensitive data.

HTTPS, which stands for Hypertext Transfer Protocol Secure, is a more secure extension of the standard HTTP protocol. HTTPS establishes an encrypted connection between a web server and a client's browser using Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL).

By using the HTTPS protocol, you can ensure that your applications are being accessed securely. Part of this is done by restricting access to your application through HTTP and only allowing access through HTTPS. If there is an issue with an HTTPS connection, many browsers will let the user know that the site may not be secure, which helps to inform users to be cautious or even avoid the site until the security issue is fixed.

By implementing HTTPS and proper certificate management, you can protect data in transit from man-in-the-middle attacks and interceptions. These types of attacks are easily executed over unsecure connections and networks and can be limited by using HTTPS. Many hosting solutions make it easy to deploy and maintain your applications with secure connections using the principles mentioned above.

4. Cross-Origin Resource Sharing (CORS)

Ensuring that your services and resources are only accessed by trusted domains is another easy way to minimize potential exploits. Creating a CORS policy allows your applications to figure out what traffic to block and which to let in, depending on where it originates from.

Proper CORS headers can allow or deny access from other domains to resources. This helps to prevent cross-site request forgery and cross-site scripting attacks. By properly configuring CORS headers, you can restrict access to your web application's resources to trusted domains and reduce the risk of these types of attacks.

Many frameworks will have CORS functionality built directly into them so it is available out-of-the-box and extremely easy to configure. For example, in Spring Boot we can set up a CORS policy like this:

This example configuration stipulates the following:

Allows all resources to be accessed from https://example.com using any of the HTTP methods GET, POST, PUT, DELETE, and OPTIONS.
The * value for allowed headers means that any header is allowed in the request.
The allowCredentials setting is set to true, allowing credentials to be sent in the request.
The maxAge value of 3600 indicates that the preflight response can be cached for up to one hour.

Using even a simple configuration like the one above can add a massive amount of security to your application. As mentioned, many other frameworks have similar configuration options available.

5. Penetration testing

Our fifth suggestion is to implement penetration testing as part of your application security measures. Penetration testing is a method of testing an application's security by simulating a cyber attack. You can use it to identify vulnerabilities and weaknesses in a web application's security that an attacker could exploit.

To perform a penetration test, a team of security experts uses specialized tools and techniques to try to gain unauthorized access to the web application and its data. They then use the results of the test to identify and fix any vulnerabilities.

There are three types of penetration testing: white box, black box, and grey box. Let's take a look at each of the styles in more depth.

White box penetration testing

White box penetration testing involves sharing full network and system information with the tester, including network maps and credentials. The testing team will essentially be given as much information as possible to save time and reduce the overall cost of an engagement. A white box penetration test is great for simulating a targeted attack while utilizing as many attack vectors as possible.

Black box penetration testing

In a black box penetration test, no information is provided to the tester at all. Typically the most costly and time-consuming option, the pen tester in this instance follows the approach of an unprivileged attacker, from initial access and execution through to exploitation. In most scenarios, this is how attackers would operate, without knowledge of the system's internal workings. Because of the nature of this type of testing, there is a chance that potential vulnerabilities will be missed, and heavily depends on the skills of the tester executing the testing.

Grey box penetration testing

In a grey box penetration test, limited information is shared with the tester. Usually, this takes the form of login credentials or another mechanism for gaining access to the system without force. Grey box testing can help organizations understand the level of access a privileged user could gain and the potential damage they could cause. This can then help the organization implement the correct controls to mitigate the damage caused once an attacker has gained access to the application.

Adopting any of the penetration test techniques mentioned above is a great addition to your web application security practices. Many different firms and tools are available to assist with your pen testing needs.

6. Adopt a DevSecOps Approach

A DevSecOps approach involves bringing security experts into the development process. These experts integrate security testing into the development and operations process at every stage of the software development lifecycle. Much of these efforts include automating security controls, especially within the CI/CD pipeline used to build the application. DevSecOps aims to build security into the web application from the start, rather than adding it as an afterthought.

DevSecOps uses preventive measures against injection attacks, cross-site scripting, and sensitive data exposure, to avoid introducing vulnerabilities. Many different tools can be used within DevSecOps workflows. Examples of DevSecOps tools include:

SAST (Static Application Security Testing) tools
DAST (Dynamic Application Security Testing) tools
Container Security Tools
Infrastructure as Code (IaC) Security Tools
Vulnerability Management Tools
Secret Management Tools

By using the tools above, a high degree of automation and security can be added when building and maintaining web apps. These tools cover everything from scanning code and applications for vulnerabilities to ensuring that the infrastructure where the code is deployed is secure.

7. Secure Configuration and Deployment Practices

Properly configuring and deploying your web application is crucial to maintain its security. This includes following best practices when setting up your web server, securing your database, and implementing secure coding practices.

A big factor in this is making sure that your organization and team have the correct skillsets to handle a secure deployment of the application. This also will involve ensuring that the deployment checklist and steps that will take place are coordinated. Each step should take security best practices into account.

Making sure that the servers and database configurations are set up correctly is also important. Making sure that servers are hardened and not easily accessed by bad actors should not be overlooked and preferably audited as part of the deployment checklist. This is extremely important for database servers where sensitive data is stored at rest.

Many servers and CI/CD pipelines come built-in with the capabilities to adopt best practices. Be sure to research and follow the recommended security configuration as outlined in the docs provided by the vendors of these products.

8. OWASP's Application Security Checklist

Following OWASP's comprehensive list of security measures improves the security of your web application and protects against potential threats. This checklist covers a wide range of security measures for your web application, including authentication and access controls, input validation, error handling, and encryption. By following this checklist, developers can ensure that they implement the most up-to-date and effective security measures.

Although many of the topics are covered in this breakdown, it is good practice to make all technical participants in a project aware of the OWASP Application Security Checklist. As part of this, during code and deployment reviews, the checklist should be used as a reference to make sure that best practices are enforced.

9. Follow Proper Logging Practices

Monitoring and logging activity on your web application helps identify potential security threats and provides valuable information for forensic investigations in the event of a security breach. By keeping a detailed log of each application event, it is easy to trace the steps of an attacker and seal the vulnerability from being exploited in the future.

Proper logging practices also ensure that logs are not easily accessible to outside attackers. Just as internal investigators may use logs to identify how a breach occurred, attackers can also use data within the logs to plan an attack or see vulnerabilities.

When data is pushed to the logs, you should ensure that any sensitive data is masked or not included in the log statements. Data like credit card numbers, passwords, and other sensitive data should never make it into a log file without at least being masked. If an attacker gets access to a log with this type of data, it can be as detrimental as them getting access to the application itself.

Lastly, you should also ensure that debug log statements that print to a console or response are not pushed out into production code. They involve something as simple as a console.log in a JavaScript file which may expose an error occurring that the attacker could exploit.

10. Use a Web-Application Firewall (WAF)

Implementing a web-application firewall (WAF) helps protect your web application from common web-based attacks. Exploits such as cross-site scripting, SQL injection, and denial of service attacks can easily be warded off by a properly configured WAF. A WAF analyzes incoming traffic to your application and blocks any malicious requests.

Although it is not a silver bullet against all web-based exploits, WAFs are relatively simple to implement and can be a first line of defense for incoming traffic to the application. If you are deploying your application on the cloud, many cloud providers offer a WAF as part of their stack. For something more agnostic to the platform you are deploying your app to you could use Cloudflare WAF or Wallarm Cloud WAF, just to name a few.

Using StackHawk DAST for Web Application Security

Stackhawk is a dynamic application security testing (DAST) tool that tests the security of web applications. It identifies vulnerabilities and weaknesses in a web application's security before you deploy the app to production. StackHawk can automate testing by scanning and executing potential attacks against web applications and APIs. A report is then created showing potential vulnerabilities and leads developers to potential fixes.

The benefits of using DAST for web application security include:

Comprehensive testing: DAST tests for a wide range of vulnerabilities, including injection attacks, cross-site scripting, and sensitive data exposure.
Continuous testing: You can set DAST up to run automated tests regularly to catch potential vulnerabilities early on.
Easy integration: You can easily integrate DAST into your development workflow, allowing you to catch and fix vulnerabilities as part of your regular development process.

For more information on exactly how StackHawk works, check out our comprehensive blog post.

Web Application Security FAQs

Have more questions about Web Application Security? Below we have compiled a few common questions and comprehensive answers to help you and your team keep your web applications safe.

What Are the Security Requirements for a Web Application?

The security requirements for a web application depend on the specific needs and goals of the application. However, the following are considered the most important security requirements:

Authentication and Access Control: Ensure that only authorized users can access the web application and its sensitive data.
Data Encryption: always encrypt sensitive data, both in transit and at rest, to protect it from unauthorized access.
Input Validation and Sanitization: Prevent web applications from accepting malicious data by validating and cleaning user inputs.

These three security requirements are closely interrelated; ensure that you implement them correctly to provide robust security for web applications.

How Do You Maintain Web Application Security?

Maintaining web application security involves regularly reviewing and improving upon existing security measures to ensure that your web application remains protected against potential threats. Here are some best practices for maintaining web application security:

Keep software and libraries up to date: Updating your web application's software, libraries, and extensions regularly is essential as it protects your app from attackers who are always on the lookout for the latest security vulnerabilities and know how to exploit them.
Implement secure coding practices: Following best practices for secure coding helps prevent common vulnerabilities such as injection attacks and cross-site scripting. This includes validating and sanitizing user input, properly handling sensitive data, and following best practices for error handling and logging.
Regularly test for vulnerabilities: Security assessments and penetration testing can identify potential vulnerabilities in your web application and allow you to fix them before attackers exploit them.
Monitor and log activity: Regularly monitoring and logging activity on your web application helps identify potential security threats and provides valuable information for forensic investigations in the event of a security breach.
Keep regular backups: Having a backup system in place is a key method for safeguarding your web application's data. Store backups on a separate server or device, such as a home computer or hard drive, to protect them from potential attacks on the main server. You can also store backups on a cloud-based platform, which allows for easy access from anywhere.

Conclusion

To ensure the security of your web application, you must regularly review and improve upon existing security measures. This can include input validation, authentication, access control, TLS, and CORS, as well as following best practices for secure coding and deployment. Using tools like StackHawk can help identify and fix potential vulnerabilities before attackers exploit them.

By following these best practices and regularly reviewing and improving upon your web application's security measures, you can ensure that your web application is protected against potential threats and maintain its security over time.

Looking to take the first step towards making your applications more secure? Sign up and try out StackHawk for free! Scan your code, detect potential vulnerabilities, fix, and repeat. By including StackHawk in your CI/CD pipeline, you can ensure that every commit is scanned automatically and that your application is secure before it hits production.

Learn more

Read on to see how StackHawk’s CSO, Scott Gerlach talks about “Shift Left” being more than just a buzzword here.
Check out why Omdia’s On the Radar report highlights StackHawk as an “interesting alternative to most other DAST tools” here.
Getting started with StackHawk? Check out Advice and Answers from the amazing StackHawk team here.

Understanding SOC 2 Security Compliance and Testing

Matt Tanner

Anyone who is working in a highly regulated industry or is a SaaS provider has likely heard about SOC 2 compliance. SOC 2 certification has become the gold standard of security for many technology companies. It guarantees a high level of information security and a promise to manage customer data in a private and secure way through the effective implementation of the organization's controls. SOC 2 compliance can take varying amounts of time and effort to achieve, but in our modern world of daily security and data breaches, it’s a must for many organizations.

In this blog, we will cover some of the building blocks of SOC 2 security testing. We will go over what it is and why it is important and finish off with some pointers on how to achieve SOC 2 compliance, how to build SOC 2 compliant applications and APIs, and look at how StackHawk can assist developers in their SOC 2 efforts. Let’s start by looking at what SOC 2 security testing entails.

SOC 2 (Service Organization Controls 2) security testing is a type of audit that assesses the security controls of a service organization. The audit is performed by a certified independent auditor who will evaluate the organization’s controls related to the security, availability, processing integrity, confidentiality, and privacy of the systems and data that the organization uses to deliver its services. The audit is designed to help organizations demonstrate to their clients and stakeholders that they have strong controls in place to protect sensitive data and systems. The audit is based on the AICPA (American Institute of Certified Public Accountants) Trust Services Principles and Criteria, which provide a framework for evaluating the design and effectiveness of controls. The results of the audit are consolidated into a SOC 2 report, which summarizes the findings of the audit and provides recommendations for improvement, if necessary.

What is SOC 2 Compliance?

Definition of SOC 2

SOC 2 compliance refers to the adherence to a set of standards and guidelines established by the American Institute of Certified Public Accountants (AICPA) for service organizations to ensure the security, availability, processing integrity, confidentiality, and privacy of customer data. SOC 2 compliance is a voluntary standard that demonstrates an organization’s commitment to protecting sensitive data and maintaining strong internal controls. By adhering to these standards, service organizations can assure their clients, business partners, and stakeholders that they have holistic measures in place to safeguard customer data and maintain the integrity of their operations.

What is a SOC 2 audit?

In order to determine whether a company is SOC 2 compliant, A SOC 2 audit must be performed. A SOC 2 audit is an independent examination of a service organization’s controls and processes to ensure compliance with the SOC 2 standards. The audit is performed by a certified public accountant (CPA) or a CPA firm with the qualifications, expertise, and experience in auditing and reporting on controls at service organizations. The audit evaluates the design and operating effectiveness of the organization’s controls, including security, availability, processing integrity, confidentiality, and privacy. Through this comprehensive evaluation, the audit provides a comprehensive assessment of the organization’s ability to protect sensitive data and maintain the integrity of its operations.

SOC 2 Framework and Trust Services Criteria

The SOC 2 framework is based on the Trust Services Criteria, which are a set of principles and controls developed by the AICPA. The framework is designed to be flexible and adaptable to different types of service organizations and industries. The SOC 2 framework includes five Trust Services Criteria:

Security: The organization must have controls in place to protect against unauthorized access to or use of systems and data.
Availability: The organization must have access controls in place to ensure that systems and data are available when needed.
Processing integrity: The organization must have controls in place to ensure the accuracy and completeness of data processing.
Confidentiality: The organization must have controls in place to protect the confidentiality of sensitive information.
Privacy: The organization must have controls in place to protect the privacy of personal information.

Achieving SOC 2 compliance also helps organizations meet various regulatory compliance requirements, thereby reducing the risk of fines and legal consequences.

To meet these principles and criteria, an organization may need to implement a variety of controls. Depending on the company and application, the company may need to implement controls for access, data backup and recovery, change management, and incident management. The specific controls that an organization needs to implement will depend on:

the nature of its business
the services it provides
the data it handles

Only after these criteria are met should an organization undergo a SOC audit to ensure SOC 2 compliance. From this audit, a SOC report will be issued showing whether the organization has met the requirements for SOC 2 compliance.

A SOC report is issued after a third-party auditor examines an organization. The audit is done to verify that an organization has an effective system of controls related to security, availability, processing integrity, confidentiality, and/or privacy. The report, which is issued by a Certified Public Accountant (CPA), provides reasonable assurance over the design and operating effectiveness of controls. Part of the report also clearly outlines any potential risks for customers or partners that are considering working with the organization. Since the SOC 2 report will be available to potential customers, this allows them to make an educated decision on whether to use the provider or not.

Is Penetration Testing Required For SOC 2 Compliance?

Penetration testing, also known as pen testing, is a type of security testing that is designed to identify vulnerabilities in systems and networks by simulating a cyber attack. While pen testing is not specifically required for SOC 2 compliance, it can be an important part of a comprehensive security program. Pen testing is another great tool that can be added to help organizations identify and remediate vulnerabilities in their systems.

The Trust Services Criteria that are relevant to SOC 2 compliance do not specifically mention penetration testing. However, the principles and criteria do require organizations to have controls in place to protect against unauthorized access to or use of systems and data. The audit evaluates the design and operating effectiveness of the service organization's controls, including security, availability, processing integrity, confidentiality, and privacy. Pen testing can be a useful tool for identifying these types of vulnerabilities, such as a system that allows for unauthorized access. Using penetration testing to discover vulnerabilities that could be exploited by an attacker, and remediating them can help an organization meet this requirement in the SOC 2 compliance guidelines.

In addition, some regulations or industry standards may require or recommend pen testing as part of a comprehensive security program. For example, the Payment Card Industry Data Security Standard (PCI DSS) recommends that organizations perform pen testing at least annually.

While pen testing is not specifically required for SOC 2 compliance, conducting a penetration test can be a valuable tool for identifying vulnerabilities and helping organizations meet the Trust Services Criteria.

What Are The Different Types Of SOC 2 Compliance?

Although we generally speak about SOC 2 compliance as a single entity, there are two types of SOC 2 compliance: SOC 2 Type I and SOC 2 Type II.

SOC 2 Type I compliance refers to the controls that an organization has in place at a specific point in time. A SOC 2 Type I audit is focused on the design of the controls, and it evaluates whether the controls are suitable for meeting the Trust Services Principles and Criteria.

SOC 2 Type II compliance, on the other hand, refers to the operating effectiveness of the controls over some time. A SOC 2 Type II audit is focused on the effectiveness of the controls, and it evaluates whether the controls are operating as intended and are achieving their intended results.

Both types of audits are performed by a certified independent auditor, and the results are presented in a SOC 2 report. As mentioned previously, the report provides a detailed assessment of the controls that are in place and makes recommendations for improvement, if necessary. Organizations generally will do a SOC 2 Type I audit first and, usually, 3-12 months later, will have the SOC 2 Type II audit completed to ensure they meet the requirements over an extended period.

Why Is SOC 2 Compliance Important?

SOC 2 compliance is an important criterion for organizations to demonstrate to their clients and stakeholders that they have strong controls in place to protect sensitive data and systems. By undergoing a SOC 2 audit, an organization can assure that it has implemented appropriate controls to safeguard the security, availability, processing integrity, confidentiality, and privacy of the systems and data it uses to deliver its services.

For organizations that handle sensitive data, such as financial information, personal information, or healthcare data, SOC 2 compliance is highly important. For organizations in the healthcare industry, SOC 2 compliance is crucial for ensuring the security, confidentiality, and availability of protected health information (PHI) in adherence to regulations like HIPAA. Many organizations must comply with regulations or industry standards that mandate the use of strong security controls. Personal data may be required to comply with data protection regulations such as the General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA). A SOC 2 audit can help an organization demonstrate compliance with these regulations. It helps to build trust with clients and stakeholders by showing that your organization takes security seriously and is committed to protecting sensitive data.

SOC 2 compliance is important because it helps organizations build trust, protect sensitive data, and demonstrate compliance with industry standards and regulations. It’s a surefire way to demonstrate to new and existing customers security and compliance are top of mind for your organization.

What Is The Easiest Way To Become SOC 2 Compliant?

There is no easy or quick way to become SOC 2 compliant. Achieving SOC 2 compliance requires a robust and ongoing security program that includes the implementation and maintenance of appropriate controls.

That being said, there are steps that organizations can take to streamline the process of becoming SOC 2 compliant:

Identify the specific Trust Services Principles and Criteria that are relevant to your organization. This will help you focus your efforts on the controls that are most important for your business.
Implement a security framework, such as the NIST Cybersecurity Framework or ISO 27001. These frameworks provide a structured approach to implementing and maintaining security controls.
Develop a security policy and procedures manual that outlines the specific controls that your organization has in place to meet the Trust Services Principles and Criteria.
Train employees on security best practices and the importance of protecting sensitive data.
Regularly monitor and test your controls to ensure that they are operating effectively and to identify any potential issues.
Work with a certified independent auditor to conduct a SOC 2 audit. The auditor will review your controls and provide recommendations for improvement, if necessary.
Implement strong vendor management processes to help ensure that third-party vendors also adhere to SOC 2 compliance requirements.

By taking these steps, you can help ensure that your organization has a strong foundation for SOC 2 compliance. However, it’s important to note that achieving and maintaining SOC 2 compliance requires ongoing effort and attention.

The typical SOC 2 compliance journey looks like this:

Audit Prep

At this stage, companies begin to uncover what is needed for SOC 2 compliance. As part of this discovery and prep process, an organization will also need to implement effective risk management strategies to identify and mitigate potential security risks. An organization will create policies and processes to adhere to the needs of SOC 2 compliance guidelines. The organization will train employees on their roles in attaining SOC 2 compliance and make changes to any technical configurations to meet SOC 2 requirements. This phase generally takes about one to three months.

SOC 2 Type I Audit

After the audit prep, some organizations will choose to do the optional SOC 2 Type I audit. As mentioned, this audit essentially proves that at this point, your business is compliant. This is when you can start the clock on attaining the SOC 2 Type II certification.

Evidence Collection

Once the clock has started, there is a three to twelve-month evaluation period that is part of the SOC 2 Type II evaluation process. During this time, the auditor will collect evidence to show long-term proof of SOC 2 compliance. This is because SOC 2 Type II certification is based on the ongoing ability of an organization to demonstrate compliance, unlike the point-in-time verification done in a SOC 2 Type I audit. During the evidence collection period, the auditor will document processes, policies, and controls that are being maintained by the organization.

SOC 2 Type II Audit

After the evidence has been collected and verified, the auditor will come in and do an on-site audit. Depending on the size of your organization, the scope of your business, and other factors, this part could take anywhere from a few days to several months. The time needed is determined by the amount of time needed for the auditor to be satisfied that they have covered all the necessary bases. After the audit is concluded, usually within a few weeks, your organization will receive the final SOC 2 Type II audit report.

Annual Refresh

Each year, the organization will need to do an annual refresh to show continuous compliance with the principles and criteria of SOC 2 compliance. By doing this, organizations know that SOC 2 compliance is being maintained on a daily, weekly, and monthly basis, even after the business has passed its initial audits.

The complexity of this process may vary from organization to organization but the sequence of events generally follows this path. Since certain periods are baked into the compliance framework, businesses can usually guarantee that achieving SOC 2 Type II compliance will happen no sooner than three months after the SOC 2 certification process has begun.

How Does SOC 2 Impact Your APIs?

Many companies have a suite of APIs that drive core business functionalities. There are very few businesses, technical or not, that do not have APIs driving at least a part of their products and services. Of course, APIs are also impacted by the requirements of SOC 2 compliance. When it comes to APIs, SOC 2 compliance can impact them in several ways:

APIs that handle sensitive data may be required to comply with SOC 2 to demonstrate to clients and stakeholders that they have strong controls in place to protect that data.
Organizations that use APIs to access sensitive data may require their API providers to be SOC 2 compliant to ensure the security and integrity of that data.
APIs that are not compliant with SOC 2 may be less attractive to potential clients and partners, as they may be seen as less secure and reliable.
Achieving SOC 2 compliance may require organizations to implement additional controls and processes related to their APIs. This can include additions such as authentication and authorization controls, data encryption, and incident management controls.

Overall, SOC 2 compliance is important for APIs that handle sensitive data. Making sure your APIs adhere to SOC 2 policies and controls is likely to be required by clients and partners to ensure the security and integrity of that data.

How To Build SOC 2-Compliant APIs

To build SOC 2-compliant APIs, you will need to implement controls that meet the Trust Services Criteria. This will likely involve building or enhancing your APIs from a few different angles. A SOC 2-compliant API will require a combination of technical, physical, and administrative controls. Some specific steps you can take to build SOC 2-compliant APIs include:

Implement authentication and authorization controls to ensure that only authorized users have access to your APIs.
Implement encryption to secure sensitive data in transit and at rest.
Implement data backup and recovery controls to ensure that data can be recovered in the event of a disaster or data loss.
Implement change management controls to ensure that changes to your APIs are properly tested, approved, and implemented.
Implement incident management controls to ensure that security incidents are promptly detected, investigated, and resolved.
Implement a security awareness and training program to educate employees about security best practices and the importance of protecting sensitive data.
Regularly monitor your APIs and their associated controls to ensure that they are operating effectively and to identify any potential issues.

It's important to note that this is just a high-level overview of how SOC-2-compliant APIs can be built. The specific controls that you need to implement will depend on the nature of your API and the data it handles. The best way to ensure that your APIs will meet compliance requirements is to consult with a security expert or a certified independent auditor. Doing this can help you to determine the specific controls that are appropriate for your APIs.

Dynamic application security testing (DAST) tools are designed to identify vulnerabilities in web-based applications. DAST tools work by analyzing the application's behavior during runtime, as a black box security testing technique. A DAST tool can help to easily identify vulnerabilities that may impact your ability to achieve SOC 2 compliance. These tools can also ensure that applications and APIs that are being built or updated do not have security defects that could affect your SOC 2 compliance. Using a DAST tool is a great way to ensure that developers are creating secure code in an automated fashion.

It's also important to note that running a DAST tool whenever code is committed to the source code repository is possible. Matter of fact, this is the best way to ensure that code is always SOC 2 compliant and is confidently being produced without defects. If defects are found, they can be remedied immediately instead of just before a production release, or worse, after the vulnerability has already been exploited in production. When code is committed, the application is built from the latest source code and the DAST tool can then execute its set of tests against the latest build. Instantly giving feedback to developers about potential vulnerabilities and any security issues which could impact SOC 2 compliance at the application level.

To use a DAST tool for SOC 2 compliance, you will need to:

Identify The Scope of Testing

Determine which applications and systems need to be tested, as well as which Trust Services Principles and Criteria the testing should focus on. Understand the vulnerabilities which can be identified by the DAST tool, as well as its limitations. Once the scope of testing is determined, you can move forward into configuring and using the tool.

Configure The DAST Tool

Set up the DAST tool to scan the appropriate applications and systems, and configure any relevant settings or preferences. Depending on the tool, you may configure it to crawl your application automatically, supply it with defined application paths, or use a mixture of both.

Conduct The Scan

Run the DAST tool to scan the applications and systems. This may involve interacting with the application in various ways to simulate how the application will behave while in use and identify vulnerabilities. The scan will test the application for vulnerabilities against known and possible attacks and monitor how the application reacts.

To ensure the most coverage and ongoing SOC 2 compliance, it is best to use an automated scanning process. The best way to do this is to use a tool, like StackHawk, that can be integrated directly into the release pipeline, which will continually test the code. This ensures that as code is written and committed, it is secure.

Review The Results

Review the results of the scan to identify any vulnerabilities that have been identified. Depending on the tool, this may consist of a report which contains the identified vulnerability, the severity, and impact, as well as potential fixes.

Remediate Any Vulnerabilities

If any vulnerabilities are identified in the results of the scan, take steps to fix them. This generally involves refactoring the code to get rid of the security defect. Of course, sometimes this also may involve applying patches, updating software, or implementing additional controls. Once the vulnerability is fixed, follow processes to verify that the fix is effective. As mentioned above, the best way to verify that the fix has been applied and is effective is to automate the DAST testing process. The easiest and most reliable way is by making DAST scans run automatically as part of the CI/CD pipeline. This process will then automatically run another scan with the DAST tool to ensure the fix is acting as intended and the vulnerability is resolved.

Document The Testing Process

Document the testing process, including the scope of the testing, the configuration of the DAST tool, and the results of the scan. This documentation will be useful if you need to demonstrate compliance with SOC 2 to an auditor or other stakeholders.

It's important to note that DAST tools are just one part of a comprehensive security program, and they should be used in conjunction with other controls and testing methods to ensure that your systems and data are secure. There are a variety of testing tools and methods available and by layering them, you can create an extremely robust application security program.

Using StackHawk For SOC 2 Compliance

StackHawk is a DAST platform that provides testing tools for web applications, APIs, and other types of services. As we explored above, DAST tools can easily and effectively be used to identify vulnerabilities that may impact SOC 2 compliance. Knowing this, StackHawk can be used as part of a comprehensive security program to help achieve and maintain SOC 2 compliance. Specifically, you can use StackHawk to:

Conduct a vulnerability scan to identify vulnerabilities in your web applications and APIs.
Remediate any vulnerabilities that are identified since StackHawk guides developers on how fixes can be achieved.
Verify that code fixes and refactoring have remedied any vulnerabilities that were discovered in the initial scan
Add StackHawk to your CI/CD pipeline to scan for vulnerabilities on an ongoing basis, as code is created and before it hits production.
Document the testing process, including the scope of the testing, the configuration of StackHawk, and the results of the scans.

Adding StackHawk to your security and SOC 2 compliance efforts is a great way to ensure applications are being written securely. StackHawk has a massive amount of functionality that can easily be configured and executed to assist your team in building SOC-2-compliant systems.

Wrapping Up

When it comes to showing users and customers how secure your platform is, SOC 2 compliance is a must-have. SOC 2 compliance guarantees that your platform meets high standards for security and can be trusted. In this blog, we looked at some key parts of SOC 2 security testing, including what it is, why it is important, and how to build and test applications and APIs to ensure SOC 2 compliance.

It's important to note that SOC 2 compliance is not a one-time event; it requires ongoing maintenance and monitoring to ensure that controls remain effective over time. Making sure that your organization continues to maintain SOC 2 compliance within existing services and new ones must be the approach moving forward.

Lastly, we looked at how StackHawk can be used to move your SOC 2 compliance testing forward. By using StackHawk's DAST platform, you can ensure that vulnerabilities that can impact SOC 2 compliance are remedies early in the development of the application or service. Try StackHawk out for yourself to help you build SOC 2-compliant applications, services, and APIs.

Policy Management: Speed Up Scans and Cover Special Test Cases

Omar Alkhalili

When HawkScan scans an application, it uses a scan policy to determine which vulnerability tests to run against that app. Scan policies are a collection of enabled and disabled plugins, and plugins can be thought of as individual vulnerability tests. The plugins that are enabled in the scan policy will be run when HawkScan uses that scan policy to scan an application.

With default settings, HawkScan will run its default scan policy with a curated selection of plugins based on their quality and general applicability for use with any application. We also provide scan policies for other use cases, such as scanning against OpenAPI/REST, GraphQL, or SOAP applications, or scanning for the Log4Shell vulnerability. Traditionally, this has been configured from the StackHawk YAML configuration file. Now scan policy settings can be managed directly for each application within the StackHawk Platform. Not only can scan policies be selected for use with HawkScan, but now they can be customized by allowing fine-tuned control over which plugins are enabled and disabled within the scan policy.

Visual learner? Jump to the video overview

Selecting a Scan Policy

Scan policies can be set for an application on the settings page for that application. For example, if we are scanning an application with a REST API, we can select the OpenAPI/REST API scan policy, which will run a selection of enabled plugins customized for REST applications. Within the application's settings, we can change the policy from "HawkScan Default" to "OpenAPI/REST API."

Now subsequent scans against this application will use the OpenAPI/REST API scan policy. For best results, it is suggested to specify an OpenAPI spec in your StackHawk YAML configuration when running this application scan policy. More on that here.

Customizing a Scan Policy

To customize a scan policy, we can select any of the available scan policies and click the "Customize Policy" button. As an example, I will use the "HawkScan Default" scan policy for a scan against a vulnerable Django app.

This will bring us to a page that shows us all available active and passive plugins that can be run with HawkScan. Checking or unchecking one of the plugins will enable or disable that plugin. When customizing a policy, there will already be some plugins that are enabled. In this example, I will enable a plugin that is disabled by default in the HawkScan default scan policy called "Source Code Disclosure - File Inclusion" (ID 43). This test detects vulnerability to directory traversal attacks. I will also disable a plugin called "Proxy Disclosure" (ID 40025) due to that plugin sometimes experiencing false positives.

First I find these plugins in the active plugins list and check/uncheck them.

Toggling these check boxes will save the application scan policy. By backing out to the application settings page, the application scan policy will now be labeled as customized.

Now it's time to run a scan. If we run a scan against this application, it will use the customized scan policy. Below you can see that the plugin added to the scan policy fired an alert as the corresponding vulnerability was discovered in the app.

I hope you enjoyed reading about our new Scan Policy Management feature. If you'd like to learn more, check out our docs on this feature.

📺 Watch a Quick Demo

[Video]

Decoding DAST vs SAST: Maximizing App Security

Matt Tanner

SAST vs. DAST: Which to Choose?

In the world of application security testing, two types of testing reign supreme: DAST and SAST. Both toolings offer extensive benefits to any organization’s security stack by identifying vulnerabilities through comprehensive testing. Both focus on deeply analyzing source code and application functionalities to diagnose potential security issues accurately.

In this article, we will look at the age-old question of DAST vs SAST by understanding what each solution provides and the key differences in how and when to use them. We will also cover other available tools in the AppSec space that can be paired well with these solutions and provide a holistic approach to application security. With the agenda set, let’s get started.

What is Dynamic Application Security Testing (DAST)?

Dynamic application security testing, usually shortened to DAST, is a black box testing method for testing software that involves examining an application while it's running. This “black box” approach to application testing means that the testing tool has no knowledge of the application's internal interactions or design.

A DAST tool simulates attacks against the running application and observes its responses to identify vulnerabilities such as SQL injection or cross-site scripting vulnerabilities. Based on the outcome of each attack, the tool can help to find security vulnerabilities and determine whether the application is vulnerable and could be susceptible to a real malicious attack. These findings allow developers to fix the security defect before the source code is pushed out into the wild.

When to use use DAST?

A DAST tool should be used early on in the Software Development Lifecycle (SDLC). By moving this testing up earlier in the development process, also known as “shifting left”, the security issues can be fixed while active development is happening. A DAST tool can be a great help to all developers and allow them to discover security flaws, coding errors, and defects they've inadvertently put into the code. By nature, DAST tools find issues that are accessible and potentially exploitable, which is great for identifying high-priority items.

What is Static Application Security Testing (SAST)?

Static application security testing, usually shortened to SAST, is a type of “white box” testing that scans application code statically. SAST tools scan and analyze source code to find source code vulnerabilities by reading through each line of code. When a known vulnerability is identified through static analysis, developers are made aware so that they can remedy the security defect.

SAST tool scans static code of an application before the code is compiled. This also means that source code can be scanned even if it is not in a runnable state, meaning that a SAST solution can be implemented before the first line of code is committed. By doing this, any potential vulnerability that is introduced can be found immediately, versus being detected only once the code is in a runnable state.

When to use SAST?

Like DAST, SAST tools should also be used very early in the development process. Once you find a SAST tool that supports the language you are coding in, it can be moved into the development process. If a project involves writing code, a SAST tool is highly recommended to detect security vulnerabilities at the moment of inception.

Benefits of Combining SAST and DAST

Although SAST and DAST represent two different testing methodologies, combining SAST and DAST offers several significant benefits:

Comprehensive Security Testing: SAST and DAST together can identify a wide range of security vulnerabilities, including those that may not be detectable by one approach alone. This dual approach ensures thorough coverage of both static code and runtime behavior.
Early Detection: SAST helps identify security vulnerabilities early in the development process, allowing developers to address issues before they become ingrained in the codebase. DAST, on the other hand, identifies vulnerabilities in running applications, providing a real-world perspective on security flaws that can actually be exploited.
Improved Security Posture: By leveraging both SAST and DAST as well as other security testing methods, organizations can enhance their overall security posture beyond using just a single tool or method. Overall, this helps with reducing the risk of security breaches and ensuring holistic protection against potential threats.
Cost Savings: Identifying and fixing security vulnerabilities early in the development process can save organizations significant time and money. Early detection means fewer costly fixes and less disruption to the development lifecycle. By using both SAST and DAST together, you can detect vulnerabilities early and also understand which ones can actually be exploited, avoiding fixing defects which are false positives.

Choosing the Right Tools

Selecting the right SAST and DAST tools is essential for rounding out your application security testing stack. Here are some key factors to consider when looking at both types of tools:

Accuracy: Look for tools that can accurately identify security vulnerabilities with minimal false positives. Accurate tools help streamline the remediation process and ensure that critical issues are addressed promptly.
Coverage: Choose tools that support a wide range of programming languages and technologies. Comprehensive coverage ensures that all aspects of your application are tested for potential security weaknesses.
Integration: Consider tools that can seamlessly integrate with your existing development tools and workflows. Integration with CI/CD pipelines, version control, and other development tools within your developer workflow can help streamline the testing process.
Scalability: Select tools that can scale to meet the needs of your applications. While some tools may run well on smaller projects, testing with them at scale may not be as efficient. Scalable tools ensure that your security testing can grow with your application and support the technologies you plan to scale with.

Best Practices for SAST and DAST

Although you can just take any set of tools and toss them into the mix for developers to use, it's still best to have some sort of plan and method to the madness. When it comes to implementing SAST and DAST effectively, remember to follow these best practices:

Integrate SAST and DAST into the Development Process: SAST and DAST should be integrated into the development process to ensure that security vulnerabilities are identified and fixed early. This integration, often referred to as “shifting left,” helps catch issues before they become critical. Developers working on the code should feel empowered to use the tools and also be held accountable to ensure their usage.
Running SAST and DAST Regularly: Regular testing is essential to maintain a secure codebase. SAST and DAST should be run frequently to identify and address security vulnerabilities in a timely manner. One of the best ways to do this is to run these testing tools within CI/CD pipelines when a build is kicked off, as part of a pre-commit hook, or an automated pull request policy/branch protection rule.
Correlating Results: Don't use the results from each tool independently, instead try correlating the results of SAST and DAST tests to help identify potential security vulnerabilities more effectively. By combining insights from both tools, organizations can gain a better understanding of their security posture and more effectively triage any issues.

Implementing SAST and DAST Effectively

Beyond best practices, there are also some pointers to look at for effective implementation of SAST and DAST. A Successful integration of these technologies requires a combination of people, process, and technology. With this in mind, organizations should:

Develop a Comprehensive Security Testing Strategy: A well-defined strategy that includes both SAST and DAST is essential. This strategy should outline the goals, processes, and tools for security testing.
Train Developers and Security Teams: Training is crucial to ensure that developers and security teams are proficient in using SAST and DAST tools and techniques. Regular training sessions can keep teams updated on the latest security practices.
Integrate SAST and DAST into the Development Process and Workflows: Seamless integration of SAST and DAST into the development process ensures that security testing becomes a natural part of the development lifecycle. This integration helps catch vulnerabilities early and reduces the risk of security breaches.
Continuously Monitor Applications for Security Vulnerabilities: Once you've got everyone trained and your testing tools running, continuous monitoring is the next essential step in maintaining a secure application. Regular scans and real-time monitoring can help identify and fix vulnerabilities promptly, ensuring ongoing security.

By following these best practices and the considerations for implementing SAST and DAST effectively, organizations can significantly enhance their application security and protect against potential threats.

Wrapping up

Identifying any major or minor security flaw early on in the SDLC is the most efficient and scalable way to increase application security. With the abundance of tools available, adding SAST and DAST tools to your application's security arsenal is a great option. Even better, adding these tools to your organization's SDLC has never been easier, with many even offering deep customization and direct integration with CI/CD pipelines. As you can see, it's not so much about “SAST vs DAST” but ideally about how to layer the various tools together. Using these platforms is the best way to actively prevent and monitor many of the vulnerabilities and attacks outlined in the OWASP Top Ten. Keeping your applications secure requires multiple angles of prevention and monitoring to ensure a holistic approach to application security.

StackHawk offers a best-in-class DAST tool that is easy to configure and developer-friendly. The platform offers blazingly fast scans right in your CI/CD workflow, and an easy-to-understand report helps developers identify and remedy any security vulnerability that is discovered. To make things even easier, StackHawk easily integrates with Snyk, a popular SAST tool, to offer the best of both worlds by combining results between the two platforms. Ready to up your application security testing game? Sign up for StackHawk today to get started!

Improvements to the StackHawk Jira Cloud Integration

Sam Volin

StackHawk has recently made a few improvements to our Jira Cloud Integration.

Atlassian Jira is the premier software planning and project tracking software. The StackHawk Jira Cloud integration helps teams identify and track HawkScan findings within your Atlassian Jira workspace.

Tracking security with Project Management tools

A Jira workspace can have many projects and each project includes Issues, each created with a specific Issue Type. The most common Jira Issue Types used are "bug", "story", or "task". Previously, the StackHawk Jira integration would only create "bug" issues, and so that issue type was required in a Jira project to use the integration.

No longer! StackHawk findings can now be triaged into any Jira issue type that belongs to a project. This update means security teams tracking findings in Jira projects can use any issue type in any project they desire, even if it’s not a “bug”. This flexibility gives teams the ability to track software defects in development, instead of separating StackHawk “security” findings from normal software development workflows.

After installing the Jira integration, teams can now select a specific project and issue type pair they want to have preselected as the default when promoting a StackHawk finding into a Jira issue from the StackHawk platform.

Tracking security findings with StackHawk

StackHawk findings can be “promoted” to a ticket engine, including Jira Cloud. After scanning an application for vulnerabilities, Application Paths in the findings can be added and tracked on a Jira ticket.

Jira project management is extremely flexible, allowing teams to design process workflows and coordinate shared work.

For software development teams, maintaining a strong security posture can include a regular team review of defect tracking and tracing tools, such as StackHawk, Snyk or Sentry, and assigning and prioritizing work into tickets on Jira Cloud, or any preferred project management system.

The StackHawk for Jira Cloud integration will help any software development team to build quality software with a strong security posture. How teams plan software development alongside security posture is a blog post for another time. But indeed, by regularly measuring and triaging events from security and code quality tools and bringing a discipline of shared quality and project organization, teams can ship secure software with confidence.

Sam Volin is a FullStack Software Engineer at StackHawk

Want to learn more? Check out the resources below:

What is API Security?

Matt Tanner

APIs are the new frontier of security. The bulk of web traffic is now going to and from APIs. Of course, some APIs are built extremely securely while others have no security implementation at all. API security has long been a blindspot for many developers and organizations and this is beginning to catch up with those who have foregone proper security measures. Many developers have just simply not protected their APIs against the possibility of an API attack.

API security is complex because there are both proactive and reactive ways to handle it. Many companies have hopped on board with the reactive approach to monitoring APIs and dealing with any issues as they happen or after they do. Less have adopted the idea of moving API security earlier in the SDLC to tackle things more proactively.

Let’s dig into the different aspects of API security including what it is, why it is important, and some helpful tips on how to improve your organization’s API security protocols.

What is API security?

API security is making sure that APIs are built with security best practices in mind and that deployed APIs require authentication and authorization for access. Sounds quite simple but API security becomes very complex, very quickly. There are many angles from which API security can be interpreted.

In the design and build phase, API security means using secure coding best practices. This means writing code that does not expose or create a vulnerability. It also means being careful that third-party dependencies don’t have vulnerabilities built in that you could be unintentionally adding to your code. Creating security gaps in your application code is extremely preventable. There are many tools available to help identify and remedy them before you hit production. In the later stages of the build phase, manual and automated testing should also be performed to identify vulnerabilities potentially missed in the earlier stages. Of course, we at StackHawk suggest also adding automated testing for each code commit by adding testing directly to your CI/CD build process.

Once built, your API will be deployed generally into different environments as it moves into production. Depending on the organization, you may see something similar to development, QA, pre-production, and finally the production environment. It is highly recommended that you implement some type of API management solution to help manage your APIs as they move through each environment. API management solutions can help with security in terms of enforcing rate limiting and quotas, keeping track of API users, enforcing authentication and authorization, and much more. API management also allows you to see your entire catalog of APIs and to easily apply uniform security to all through a single platform. API management allows for a “single pane of glass” approach to monitoring and securing your APIs.

Once the APIs have been built and deployed to production, ongoing API security monitoring is recommended. Much of the time, the API security monitoring product can be connected to your API gateway so that your API analytics can be used to monitor for anomalies. API security monitoring can detect possible malicious activity and security issues within the API traffic. If an issue is detected, the tool will then raise an alert so that teams are notified and can contain and minimize the impact.

Ongoing improvement to API security should be at the forefront of all development efforts. A great way to ensure that your APIs are secure is to monitor for issues outlined in the OWASP API Security Top 10. Let’s take a look at that next!

What are the OWASP API Security Top 10?

The Open Web Application Security Project (OWASP) is a non-profit, collaborative online community that informs and educates about various security issues within web applications. They are the community behind the OWASP Top 10. Starting in 2003, OWASP has been publishing an authoritative list of the most prevalent vulnerabilities and ways to mitigate them. With the rise in the popularity of APIs, OWASP began producing a more targeted list of vulnerabilities plaguing APIs and how to avoid them. This culminated in the release of the first OWASP API Security Top 10 list in 2019.

Let’s look at each of the vulnerabilities and a brief summary straight from the OWASP API Security Top Ten.

Broken object-level authorization

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using input from the user.

Broken authentication

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities temporarily or permanently. Compromising a system’s ability to identify the client/user, compromises API security overall.

Excessive data exposure

Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.

Lack of resources and rate limiting

Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.

Broken function level authorization

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.

Mass assignment

Binding client-provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, usually leads to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in API request payloads, allows attackers to modify object properties they are not supposed to.

Security misconfiguration

Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.

Injection

Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Improper assets management

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

Insufficient logging and monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, and pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Why is API security important?

API security is important because APIs are the driving force of much of the functionality and revenue generated by modern businesses. By letting API security go without attention, you could be inviting massive vulnerabilities and breaches into view that can be easily mitigated.

With the rise in API usage and our dependence on APIs, deploying unsecured APIs or building APIs in an unsecure manner is putting your business at a massive risk. Vulnerable APIs can leak sensitive data, allow for DDoS attacks to occur, and allow for API abuse. If an API attack were to occur, it could heavily affect the trust in your organization and massively tarnish your reputation. On top of this, there may be legal ramifications to any breach that happens from a lack of implementing the proper security measures for your APIs. API security is an important part of a sustainable business and should be one of the highest priorities, especially for those businesses that have public APIs that are easily accessed.

How to secure your APIs

Securing APIs takes many different forms. The angles to cover API security include when the API is designed and built through to when they are live in production. Many different tools can be used for this including using static code analysis dynamic application security testing tools, fuzzing, active API security monitoring, and even manual testing methods.

Building secure APIs early in the SDLC

Early in the software development lifecycle, automated security testing can be implemented and put on autopilot. There’s also an opportunity at the start of a project or with the addition of any new code to ensure that secure coding practices are put in place.

Secure coding practices include making sure that all input is validated, authentication and password management is put in place, session management is implemented and enforced, and error handling and logging best practices are followed. There are many other factors that also can be looked at to ensure code is being built and deployed securely. Making sure that these standards are enforced against any new code written can help stop vulnerabilities at the source. Keeping developers aware of these practices from the start also leads to less refactoring later if vulnerabilities are found by other tools.

One example to dig into is error handling and logging. Developers should not disclose important details that could be used to create an exploit more easily through the error handling and subsequent logging implemented in their code. This includes allowing errors to display system details, session identifiers or account information. You’ll also want to ensure that developers are not printing out debugging or stack trace information which can be viewed publicly. By setting these expectations and rules with developers, everyone who is contributing code will do so in a more security-conscious fashion.

API security also involves making sure that the infrastructure behind the APIs is secure. This means making sure that servers and databases are hardened and require strict access control for those who do have access. Another factor is making sure that all infrastructure is running the latest security patches and recommended operating systems. On top of securely built code, making sure that your infrastructure is secure reduces the possibility of exploits.

Of course, it makes sense to also include automation in your efforts early on as well. This will likely include a SAST and a DAST tool to scan and make your team aware of potential vulnerabilities.

Static application security testing (SAST) is a white-box testing methodology. A SAST tool scans your source code and related dependencies, the frameworks and libraries your application uses. During the scan, the tool refers to a predefined set of rules to detect issues and vulnerabilities, marking their exact location.

Dynamic security testing (DAST) uses a black-box approach that assumes no knowledge of the inner workings of the software being tested. This means that the DAST tests only use the available inputs and outputs for the system or API. DAST tests are dynamic since the number of inputs and outputs increases and decreases, and the data they consume or release continuously changes.

The main difference between DAST and SAST is in how they approach security testing. SAST scans the application code at rest and can be done at any point, even if the code is not ready to run. These scans discover faulty code which could be exploited. DAST tests the running application and has no access to its source code meaning that the application must be built and deployed. The DAST scans generally tend to bring back fewer false positives than SAST. This is because the existence of an exploit can be confirmed to exist more accurately versus generic pattern matching of static code analysis. Combining both SAST and DAST testing tools can be a great way to ensure a high likelihood of catching any security flaws before they reach production.

This should set most organizations up with a very robust security framework to make sure code is being generated in a secure fashion and tested robustly.

Testing before production

As code moves through your company's SDLC and processes, it will likely reach more than a single environment before getting pushed into production. It is a good practice to also test once the code leaves the development environment. In the QA or testing environments, manual API testing can help to uncover bugs that may not have been revealed by automation. It’s also a good practice for vulnerability fixes to be retested at this stage to ensure that any potential exploits are unable to occur in production.

As vulnerabilities are discovered in higher environments, code should be moved back through dev to ensure that the automated tests have a chance to discover any additional bugs introduced by fixes. If this is not possible, it would be recommended that all automation implemented in the lower environments be moved into each environment where code fixes are applied and tested. Following these practices should lead to good code quality and a reliable production deployment without any major security vulnerabilities.

Monitoring APIs in production

Lastly, once the code hits production you’ll want to implement robust monitoring practices. As secure as the code should be, it’s always best to have some type of monitoring to alert your organization of potential attacks and threats. By implementing real-time security monitoring, you can be assured that any runtime exploits that are occurring will be detected and your team will be notified immediately.

Working with your security team and using the tips above can help to create a highly secure API development and deployment framework. All aspects from development to the running production code are important and should not be understated. Many tools exist to easily implement the security practices mentioned above. Adding these tools can help to reduce development timelines and make for an easy-to-manage security standard throughout the SDLC.

Using StackHawk for API security

As mentioned above, DAST tools can be a major help when trying to uncover vulnerabilities in running code and APIs. With StackHawk you get a best-in-class DAST solution which brings automation, easy configurability, and robust testing to your code. With StackHawk, creating your API security testing configuration can be done in many different ways. One way is to run a scan to crawl your application and identify endpoints, although this can be rather inconsistent and miss API endpoints. For more complete and explicit testing, you can use an OpenAPI spec to define all endpoints as well as the expected input and output of your APIs. StackHawk also allows you to test API authorization and authentication to ensure sensitive data is protected and access control is working as anticipated.

On top of RESTful API support, StackHawk also supports GraphQL APIs, through the use of an introspection endpoint, and SOAP APIs, by uploading a WSDL to identify services. You can also use a Postman Collection to identify endpoints and add them to your security scan. Going beyond traditional API security testing tools, StackHawk allows you to support your legacy APIs and technologies as well as the latest and greatest.

To get started with API security testing and StackHawk, your first need to sign up for a StackHawk account. After you have signed up, you’ll simply need to:

Add the StackHawk config file to your project’s repo. The config file will link out to OpenAPI Spec, GraphQL introspection endpoint, Postman collection, or any other inputs used to inform the scan of your available endpoints.
Add the StackHawk scan to your setup. This can be done via the StackHawk docker container or StackHawk CLI tool. This can be added directly to your CI/CD pipeline to enable testing directly within your GitOps flow.
From here, you can start catching API security issues as they are introduced into the codebase.

Once these steps are complete, you’ll have a robust DAST tool added to your organization's security toolbelt. Combining StackHawk with a SAST solution, like Snyk, and an API security monitoring tool, you can be sure that you are building, deploying, and running your APIs in a secure fashion.

Wrapping up

In this article, we chatted about all things API security. We touched on what it is, the top vulnerabilities to look out for, and a few ways to create a robust API security framework. Although never easy, API security is seeing a massive shift in accessibility and availability. One such tool helping to put better API security in the hands of developers and reduce security risk is StackHawk. StackHawk’s DAST platform is helping organizations to build better and more secure APIs earlier in the development lifecycle. Sign up today to get started with the only DAST and API security testing tool that runs in CI/CD, enabling developers to quickly fix security issues before they hit production.

Custom Test Data for GraphQL APIs

Austin Pearigen

Why is this new feature important?

The parameters defined in a GraphQL API are meant to represent real data, in other words, actual usernames, asset IDs, query strings, and so on. Using genuine data for these parameters triggers authentic logic from your application and activates more branches of your code.

For instance, for a password update mutation in a GraphQL API, if a username or ID is provided that does not exist within the context of the application, a simple 404 is returned on the resource lookup, and none of the actual password reset code is invoked. However, if the resource can be found, all of the password reset code is exercised with the parameters provided.

This scenario illustrates how Hawkscan’s new feature, ‘Custom Test Data for GraphQL APIs’, enables deeper security testing of GraphQL APIs.! Using this new feature, users can configure lists of values they want to use in a scan for each defined parameter and one of the values will be chosen randomly for each path that parameter belongs to.

How is this new feature configured?

To supply custom values for a GraphQL API’s parameters, you need to update your `stackhawk.yml` file. Under the `app.graphqlConf` section, a new array field called “customVariables” is available, which represents a list of fields and corresponding lists of values for each key. The key represents the parameter in your GraphQL schema, and HawkScan uses the list of values to choose one on the fly when scanning a GraphQL API.

I don’t want to supply my own data, but I do want more realistic values.

Sometimes existing data isn’t always necessary and properly formatted values will still be more effective than generic default values. Leveraging the Faker library, HawkScan can now generate authentic data for a GraphQL API with a little configuration.

For instance, if a request has a phone number as one of its parameters where the type is a string and the format is phone, an actual phone number can be generated rather than a default value string that has no relation to a phone number. To use these faker values, the `fakerEnabled` parameter in the graphqlConf section of the `stackhawk.yml` file should be set to `true`. When enabled, HawkScan generates a realistic value for any parameters that are supplied in the `customVariables` section and have a provided value with the prefix `$faker:` followed by the desired format. For example, to generate an email address for a parameter, a single value should be provided “$faker:email”. Faker prefixed formats can be supplied with other custom variables, or as a singleton list to guarantee a Faker value is generated. A complete list of the available formats is available (https://docs.stackhawk.com/hawkscan/configuration/openapi-configuration.html#generating-smart-values-for-parameters)[in our documentation] (Need to put this list in a better, more commonplace in the docs for gql to share as well.)

📺 Watch a Quick Demo

[Video]

Hawk ReScan: How to Validate Fixes in a Fraction of Time

Dana White

HawkScan provides the information and tools you need to fix security vulnerabilities in your applications. But how do you know if you’ve fixed a vulnerability for certain? For instance, if you’ve incorporated HawkScan into your CI/CD pipeline, you can make a fix, commit it, open a PR, and hope that your fix passes the next test. But that scenario is time-consuming, requiring you to wait for a full build process and a full HawkScan to run.

With HawkScan 2.9, you now have the ability to Rescan Findings. Rescan only runs the plugins that were alerted on in your previous scan, allowing you to quickly iterate on vulnerability fixes before pushing code to your remote repository.

The Scenario

A new feature’s code is merged, introducing a vulnerability into your application’s code base. HawkScan reports the vulnerability as a new finding, shows you the affected paths, and provides you with feedback on how to fix it.

Great! Now you know how to fix it. So let's say, you do a quick fix and push it up to your CI platform of choice. However, it fails again. Instead of doing a full push into your CI/CD pipeline and waiting for an entire build process and scan to run, you can run a local scan on only the alerts that were previously found.

Sound familiar? It should! It's the same way you’d run unit tests on only the failed tests.

The Rescan command

Using the `hawk rescan` command will run the latest scan, or a specific scan if an ID is supplied, against your application. This rescan will only test your application with plugins that had findings on the previous run. To use Rescan, go to the StackHawk scan details page with the vulnerability. From here, you can hit the Rescan Findings button to get the code to rescan your application.

Simply copy/paste the command into your terminal and it will run a scan with only the plugins that were previously alerted on. You can see the difference between the number of plugins that were run in the first test compared to the number of plugins that were run in the rescan:

Rescanning the previous findings only took a third of the time of the original scan.

Results

StackHawk will include the findings of a rescan and show you what you fixed from the previous scan. The StackHawk Scan Details page now includes a Fixed counter that shows the number of alerts fixed between this scan and the previous scan, as well as a summary table of all fixed findings. Now that's validation!

📺 See It in Action

[Video]

Getting Started With Rescan

New to StackHawk?

Create a StackHawk account and read the Getting Started guide to complete your first scan
Don't have an app to test? Follow the Javapspringvulny Tutorial to try out StackHawk without connecting your own application or configuring an environment

Already a StackHawk User?

Read the Rescan docs to start validating fixes faster
Need some help? Reach out to support@stackhawk.com or send us a chat!

API Security Monitoring vs. Testing: A Comprehensive Guide

Matt Tanner

The hottest topic in the API realm these days seems to be API security. Looking at the OWASP API Top Ten, it’s easy to see that many APIs are not immune to the effects of poor application security. As with any topic, there are many different ways to slice and dice precisely what this means. Does security start with how the APIs are coded or when the API is available in production? Is it better to take a proactive or reactive approach to API security or both? Understanding the entire API lifecycle is crucial to effectively secure an API, as it progresses through various stages, including planning, development, testing, staging, and production. This is precisely the starting point we are looking to dive into when discussing API security testing vs API security monitoring. Both of these components hold a place in modern web API development and operations. However, it can be confusing as to where one ends and where the other begins. Let’s take a deeper look!

What is API Security?

API security refers to the practices and measures taken to protect Application Programming Interfaces (APIs) from unauthorized access, use, disclosure, disruption, modification, or destruction. Within modern software, APIs are critical to connectivity between different systems, services, and applications. Ensuring the confidentiality, integrity, and availability of APIs is paramount to safeguarding sensitive data and maintaining seamless operations.

API security, in the broadest sense, encompasses a wide range of strategies, including implementing authentication and authorization mechanisms, encrypting data in transit and at rest, and continuously monitoring API traffic for suspicious activities. API security has become an extremely hot topic in the last few years as APIs have become more critical.

What is API Security Testing?

The drive to “shift left” has meant that security has become a concern earlier in the development lifecycle. The days of security scans and testing happening just before the move to production is archaic and inefficient. Modern API security testing has moved earlier in the software development lifecycle to find bugs, defects, and any type of API vulnerability before developers are deploying code in production. This type of testing generally takes place as developers are writing the code for a service that is not yet live. Although static code scans should be part of an engineering team’s repertoire, API security testing generally tests running API code for vulnerabilities by attempting to exploit known attack vectors. By doing this, developers can be aware of potential vulnerabilities, fix them, and reduce the APIs’ attack surface.

API security testing helps to identify potential issues before the code even moves into production. Tools like StackHawk actually move this process into the CI/CD pipeline so that scans can run automatically and consistently. Some tools allow you to upload an OpenAPI spec to define the API you’d like to test. From here, the testing tool is then able to generate tests for expected input and output and even test for user access, encryption, and authentication concerns. Additionally, it is crucial to test for business logic vulnerabilities, as these can be exploited by attackers and are often missed by traditional monitoring tools.

Why use API Security Testing?

API security testing should be used as part of a modern SDLC to prevent security defects before they hit production. There’s never any guarantee that developers are following security best practices as they may be too rushed or not even aware of security flaws introduced through their code. Maintaining an updated API inventory is crucial for effective security testing, as it ensures that all APIs, including undocumented ones, are discovered and classified. Using a tool for API security testing in the early phases of development can allow developers and organizations to detect security issues and remedy them.

This also allows developers to work more quickly knowing that they have a second line of defense when it comes to detecting security defects in their code. Since API security testing can be automated, the process can be run as part of the development lifecycle without impacting developers and project timelines. The benefit of this is that security defects can be found earlier, automatically, and some tools even guide developers on how to fix the bugs they’ve introduced. Finding security defects later can lead to major overhauls of the codebase in order to remedy issues. This may require retesting of previously tested components and repetition of other late-stage SDLC activities. All of these outcomes likely will extend timelines resulting in delayed release cycles. Using API security testing leads to more secure software and a more predictable SDLC timeline.

OWASP API Top 10 Security Threats

The Open Web Application Security Project (OWASP) has identified the top 10 security threats to APIs, which are critical to address when creating APIs. Briefly speaking, here are the key areas that OWASP recommends keeping an eye on as these are the most common and critical vulnerabilities within the API ecosystem.These threats include:

Broken Object-Level Authorization: Occurs when an API does not properly enforce access controls, allowing attackers to manipulate object identifiers to access unauthorized data.
Broken User Authentication: Weak authentication mechanisms can be exploited to impersonate users and gain unauthorized access.
Excessive Data Exposure: APIs that return more data than necessary can inadvertently expose sensitive information.
Lack of Resources and Rate Limiting: APIs without proper rate limiting are vulnerable to abuse, leading to performance degradation or denial of service.
Broken Function-Level Authorization: Insufficient authorization checks at the function level can allow attackers to execute unauthorized actions.
Mass Assignment: Automatically binding user input to data models without proper validation can lead to unauthorized data manipulation.
Security Misconfiguration: Incorrectly configured security settings can create vulnerabilities that attackers can exploit.
Injection: Flaws that allow untrusted data to be interpreted as code, allowing API users to inject malicious code and leading to the execution of malicious commands.
Improper Asset Management: Lack of proper inventory and management of API endpoints can result in outdated or insecure APIs being exposed.
Insufficient Logging and Monitoring: Without adequate logging and monitoring, detecting and responding to security incidents becomes challenging.

Implementing effective security measures to mitigate these risks is essential for maintaining the security and integrity of APIs. Luckily, you don't need to find and manage these on your own since many tools to help exist!

Top Free and Open Source API Testing Tools

To identify security vulnerabilities and enhance the overall security posture of APIs, several open-source API testing tools are available. These tools are invaluable for performing comprehensive security testing and ensuring that APIs are robust against potential threats:

Postman: A widely-used API development and testing tool that allows users to send, receive, and analyze API requests. Postman supports automated testing and can be integrated into CI/CD pipelines for continuous security testing.
Swagger: An open-source toolkit for building, testing, and documenting APIs. Swagger enables developers to define API endpoints and their expected behavior, facilitating thorough testing and documentation.
JMeter: Originally a load testing tool, JMeter can also be used for security testing and performance testing of APIs. It supports various protocols and can simulate multiple users to test API performance under load.
SoapUI: A popular API testing tool that supports both SOAP and REST APIs. SoapUI offers advanced testing capabilities, including functional, security, and load testing.
Karate: An open-source API testing tool that allows users to write tests in a simple, readable format. Karate supports both HTTP and HTTPS protocols and can be used for testing RESTful APIs.

These tools are essential for identifying security vulnerabilities and improving the overall security posture of APIs. However, it is crucial to use them in conjunction with other security measures, such as access control, encryption, and secure coding practices, to ensure comprehensive API security.

What is API Security Monitoring?

API Security Monitoring goes beyond merely trying to monitor API performance. It is more focused on detecting threats within traffic coming into an API. This monitoring is usually applied to production APIs and monitors traffic as requests and responses flow through the APIs. API Security Monitoring is less proactive, in terms of preventing attacks before they happen, and more focused on being reactive by alerting companies of potential attacks and vulnerabilities that are actively being exploited.

API Security monitoring also may look at the geographic data attached to the request. Doing this can ensure that any regions that you want to exclude from using your APIs can either be blocked or teams at least alerted about traffic coming from a restricted region. This means that API security monitoring not only analyzes the request and response traffic but also makes sure the origin of the traffic is permitted.

Many times, API security monitoring tools will also allow API traffic to be intercepted and prevented from going to an upstream API while returning a custom response for the API call. This can prevent malicious traffic from overwhelming an API endpoint, potentially causing a denial of service attack.

API security monitoring is how companies can analyze traffic to ensure that APIs aren't being exploited and if they are, be notified. As mentioned, some API security monitoring platforms also allow the blocking of potentially malicious API calls and other automated flows.

Why use API Security Monitoring?

API security monitoring is an important part of ongoing threat management. Even with the most secure code, exploits can be found and go undetected until it’s too late. Monitoring for exploits and attacks that are occurring on production APIs, by using an API security monitoring tool, is a great way to create automated defenses against attackers. By detecting attacks in their early stages, attacks can be prevented or halted quickly to minimize losses. Proper monitoring can help to detect common attacks that are used against APIs, such as brute force attacks, by ensuring resource management and rate limiting are in place and working. With these limits in mind, alerts can be configured to let the support team know there may be an issue or ongoing attack. After the attack is halted, information gathered by the monitoring tool can be used to improve the code and harden the API platform for the future.

Using API security platforms can not only detect when malicious activity is occurring but actively helps to prevent and mitigate it. This may also help to detect attacks that occur as part of accidental security misconfiguration. As with any aspect of application security, having monitoring in place allows your organization to have an active defense against threats.

Should You Use Both API Security Testing and Monitoring?

Using both API security testing and API security monitoring together can help to create an extremely robust security framework for your organization. API usage has been exploding in growth over the past few years and with that, there has been an increase in API-related security events. Because of this, using both approaches as part of your API testing regimen can help to make sure your code and platform are secure before it hits production. It also can add peace of mind when it is released into the wild. By using both API security testing and API security monitoring, you can mitigate many of the exploits and vulnerabilities outlined in the OWASP API Security Top Ten.

Using both types of tools, organizations can be proactive by testing services earlier in the software development lifecycle but also monitor potential security threats unfolding in the production environment if they do occur or slip past the security testing. With the ever-changing landscape of security and potential attack vectors, a suite of tools is recommended that cover your operations from all angles.

Getting Started with API Security Testing and Monitoring

At StackHawk, in our experience, it makes the most sense to start with API security testing and then layer in monitoring as the code goes live. Implementing API security testing should be done first since it can help to uncover defects earlier in the development process. This should be done by adding it as part of your existing automated test suites to make sure you're also including security tests on top of unit, E2E, and other API testing. Then, as APIs begin to see live traffic, API monitoring should be added on top to monitor the traffic for potential attacks occurring in real time.

For API security testing, StackHawk is a best-in-class solution which brings automation, easy configurability, and robust testing to your code. With StackHawk, creating your API security testing configuration can be done in many different ways. One way is to run a scan to crawl your application and identify endpoints, although this can be rather inconsistent and miss API endpoints. For more complete and explicit testing, you can use an OpenAPI spec to define all endpoints as well as the expected input and output of your APIs. StackHawk also allows you to test API authorization and authentication to ensure sensitive data is protected and access control is working as anticipated.

To get started with API security testing and StackHawk, you first need to sign up for a StackHawk account. After you have signed up, you'll simply need to:

Add the StackHawk config file to your project's repo. The config file will link out to OpenAPI Spec, GraphQL introspection endpoint, Postman collection, or any other inputs used to inform the scan of your available endpoints.
Add the StackHawk scan to your setup. This can be done via the StackHawk docker container or StackHawk CLI tool. This can be added directly to your CI/CD pipeline to enable testing directly within your GitOps flow.
From here, you can start catching API security issues as they are introduced into the codebase. StackHawk will perform API requests against your endpoints and inform you of any potential security issues.

Once these steps are complete, you'll have active and automated API security testing built directly into your organization's SDLC.

Next, you will add in your next layer of API protection: API security monitoring. For this, most companies either offer an SDK which can be added directly to your API code or a plugin for the API gateway or proxy you may be using. The monitoring tool will receive analytics data from the traffic running through the API which will then be monitored for anomalies. Implementing a monitoring tool is usually quite simple:

Add the API monitoring tool to your stack through an SDK or plugin
Depending on the tool, configure the tool for the type of monitoring you'd like to enable
Create your notification channels for alerting when anomalies are detected
Going forward, receive alerts any time an event of interest is detected to help detect any threats as they are happening

Some platforms to check out for API security monitoring include ThreatX, Arkose Labs, and DataDog.

With both of these tools in place, your APIs will be more secure as you build them and as you release them into the wild. Getting started can be extremely simple and definitely worth the investment.

Wrapping Up!

Implementing API security testing and monitoring is a crucial step in creating and offering secure APIs. As the frequency of API attacks increases, so does the need for tools that help developers to follow security best practices more easily. With the abundance of tools available, adding these options to your SDLC has never been easier, with many even offering deep customization. These platforms allow you to prevent and monitor for many of the vulnerabilities and attacks outlined in the OWASP Top Ten. Keeping your APIs secure requires multiple angles of prevention and monitoring to ensure a holistic approach to API security.

At StackHawk, we cover API security testing by offering a platform that is easy to configure and easy for developers to use. Blazingly fast scans right in your CI/CD workflow and an easy-to-understand report help developers to identify and remedy any security defects. Combining StackHawk with your favorite API security monitoring tool can help to create a robust security framework to decrease your security risk to keep your APIs safe from threats. Sign up for StackHawk today to get started!

Dynamic Application Security Testing vs. Penetration Testing

StackHawk

Whether we like it or not, cybersecurity is a rapidly evolving arena. It's just a matter of time before your business or organization falls victim to a cyberattack. The difference between becoming a victim and not is preparedness.

Organizations that are prepared for these attacks have a greater chance of mitigating the damage and preventing data loss. And the most effective and appropriate way to prepare is by properly implementing DAST tools and penetration testing.

Both dynamic application security testing and penetration testing are security processes used to evaluate the security of applications. However, they're not the same.

Dynamic application security testing, or DAST, is a technique to find vulnerabilities in websites and applications. It was developed as a more efficient and cost-effective alternative to penetration testing and is used by many companies today.

This post will discuss the use of DAST, who should use it, and how it works. We'll also discuss how it differs from penetration testing and why companies need it.

What Is Dynamic Application Security Testing?

Dynamic application security testing is a type of security testing performed on various kinds of applications. It's designed to identify vulnerabilities in applications that attackers could exploit. Companies can use DAST to assess the security of applications at any stage of development, from initial design to production.

Organizations can use DAST to test web-based applications, thick client applications, mobile applications, and web services. DAST is a black-box testing technique that doesn't require access to the application's source code.

DAST tools work by conducting automated scans of web applications. They crawl the application to identify potential vulnerabilities and then attempt to exploit them. If a vulnerability is found, the DAST tool will report it to the user.

Security teams use DAST to find a wide range of vulnerabilities, including SQL injection flaws, cross-site scripting (XSS) vulnerabilities, and directory traversal flaws. DAST is an essential tool for application security, as it can find vulnerabilities that would be difficult to find using other methods such as manual testing. It's also a relatively easy and quick way to assess the security of applications.

However, one should not use DAST solely to test application security, as it can only find vulnerabilities known to the DAST tool (and not business logic vulnerabilities).

What Is Penetration Testing?

Penetration testing (also known as pentesting) is an authorized simulated attack on an application, system, or network to find vulnerabilities. The end goal of pentesting is to find security risks, weaknesses, and vulnerabilities in a system, network, or application so that they can be addressed before an attacker has a chance to find and exploit them.

Penetration testing can be used to perform security testing on both internal and external applications. It can be conducted using various methods, including network and application layer attacks, social engineering, and physical security testing.

Penetration testing should be performed regularly as part of a comprehensive security program to identify and remediate potential security risks. Penetration tests can be manual or automated and have both advantages and disadvantages.

Manual penetration testing is carried out by ethical hackers who use their skills and knowledge to try and find vulnerabilities in a system. This type of testing can be comprehensive, as experienced professionals often carry it out. However, it can also be very time-consuming and expensive.

Automated penetration testing is carried out by software designed to scan for vulnerabilities. This type of testing is often quicker and more cost-effective than manual testing, but it can sometimes miss certain kinds of vulnerabilities.

How Is DAST Different From Traditional Penetration Testing?

DAST is a type of security testing that assesses the security of an application by testing it in its running state. This is in contrast to traditional penetration testing, which typically assesses the security of an application by testing it in a static state (in most cases).

DAST is a more comprehensive approach to security testing, as it can identify known security vulnerabilities within less time and with low human intervention. Companies can also use DAST to test the effectiveness of security controls, such as web application firewalls.

Traditional penetration testing is still a valuable security testing method, but it has its limitations. Additionally, penetration testing doesn't always provide a complete picture of an application's security posture.

DAST is a more modern approach to security testing that offers many benefits over traditional penetration testing.

Other Key Differences Between DAST and Penetration Testing

DAST doesn't require knowledge of the application's inner workings; all that's needed is a URL.
DAST can be performed without disrupting the regular operation of the application. Traditional penetration testing often requires shutting down the application or putting it in a "test" mode.
DAST can be performed automatically without needing a human tester. This makes DAST more efficient and less expensive than traditional penetration testing.
DevOps teams can easily integrate DAST tools with modern-day CI/CD tools to provide comprehensive security testing of web applications.

When to Use DAST vs. Penetration Testing

There's no specific answer to this inquiry. It really depends on your specific needs. DAST may be a better option if you're looking for a more comprehensive assessment of an application's security. However, penetration testing may be a better option if you're specifically interested in identifying and exploiting vulnerabilities.

DAST is generally considered less invasive than penetration testing, as it doesn't require access to the underlying systems. Pentesting can be more disruptive, as it may need access to systems and networks to test for vulnerabilities.

DAST is typically used when organizations want to assess the security of their web-based applications without disrupting business operations. Pentesting is often used when organizations want to identify and remediate vulnerabilities in their systems and networks.

On the other hand, penetration testing can help you verify the effectiveness of your security controls. This is important, as you want to ensure that your controls are working as intended.

Conclusion

DAST is growing in popularity as a complementary penetration testing method. DAST is especially useful in modern development environments where test-driven development and Agile methodologies have become more common.

In this post, we've explored the differences between DAST and penetration testing, as well as how security tests can complement each other to provide a more comprehensive testing strategy. If you're interested in learning more about how this security testing method works or want to know how to implement it into your testing strategy, we encourage you to contact us.

Thank you for reading, and we look forward to hearing from you soon!

This post was written by Keshav Malik. Keshav is a full-time developer who loves to build and break stuff. He is constantly on the lookout for new and interesting technologies and enjoys working with a diverse set of technologies in his spare time. He loves music and plays badminton whenever the opportunity presents itself.

How Does an API Gateway Improve Security? A Leader's Guide

StackHawk

When applications use a microservices architecture, it's possible for clients and microservices to communicate directly. However, this operation is suitable for a restricted functional domain where you have a small number of microservices. The greater the number of microservices available, the more complicated it will be to know which microservice should be called. All the more so since a client will often have to call several microservices to collect all the data necessary for the operation of the application.

To optimize the application, you'll need to ask several questions, limit the number of requests sent to the back end, and manage problems such as security. You can use an API gateway to do this.

In this post, we'll explain how you can use API gateways to improve security.

What Is an API Gateway?

An API gateway acts as a single entry point for the client (web application, mobile application, etc.) and protects the back-end APIs by monitoring and securing traffic and ensuring the availability of services.

It can do several things, including the following:

Aggregate or disaggregate different APIs
Realize the transformation of protocols or data, the use of non-internet compatible protocols, and the caching and orchestration of different APIs
Centralize security, thus avoiding having to do it at the level of the APIs of the application server
Participate in the availability and scalability of the application
Contribute to the simplicity of API consumption by consumers

Why Use an API Gateway Instead of Direct Client-to-API Communication?

The greater the number of APIs available, the more complicated it is to know which API should be called. This is all the more so since a client often calls several APIs to collect the data necessary for the operation of the application.

Without an API gateway, client applications send requests directly to APIs with the following implications:

Applications must precisely know all the services to call them.
Network latency may increase by forcing multiple round trips between the client application and the back end.
Ensuring data security is also more complicated since all services are exposed publicly, thus increasing the attack surface.

In addition, as the API gateway abstracts from the actual implementation of the service or services, it may present consumers with only the necessary information and manage API versioning more simply.

How Is an API Gateway Different from an API Manager?

There are some differences between an API manager and an API gateway. To begin with, in terms of functionality, an API manager has a much larger number of functions than an API gateway, which is more restricted to API security and targeting filters.

In practice, an API manager incorporates an API gateway in its structure, acting as if it were a management system. The tool comprises features that facilitate the development and application of other APIs. These help reinforce usage rules, improve access control, collect and analyze usage statistics in detail, and manage the entire API lifecycle.

How API Gateways Help with Security

A successful cyberattack can expose company, application, and user data. With that in mind, API gateways increase the system's security, protecting it from attacks by malicious agents.

It is possible to add a protective layer that fights vectors triggered by digital attacks using a buffer zone. This turns the application's focus to the business while the cache and security are in charge of the API gateway.

API gateways provide a single access point for the exchange of flows, controlling calls between third-party systems and the traffic of data. In addition, they offer greater control over shared information through the centralization of everything in one interface.

With an API gateway, it's possible, for example, to limit the permission of an accounting partner so that they can only view financial information, blocking the view of patient data. As a result, the organization can be sure the data is safe, and so can users. At the same time, tech teams do not need to exert as much effort. Instead, they can rely on a single place to manage integrations between numerous systems. That means more data security and less work.

An API gateway does not only coordinate and control services that are immune to attacks. It also guarantees that the system as a whole will not get affected if there's a vulnerability. Thus, in addition to reducing damage in case of attacks, this strategy helps users, since the other features remain normal during an attack.

Using an API gateway simplifies your architecture, makes it more secure, and reduces the network load since it ignores the actual implementation of the microservice or microservices. By disregarding the actual implementation of the microservices or even by calling old applications in monolithic type architectures, for example, it can standardize the return message while allowing calls to different types of services: API, SOAP, and REST among others.

A successful cyberattack can expose company, application, and user data. With that in mind, API gateways increase the system's security, protecting it from attacks by malicious agents

API Gateway Security Best Practices

An API gateway must be independent and sit between the client and the back end. As the microservices abstraction layer, it acts as a reverse proxy by redistributing requests to various corresponding microservices. It therefore becomes an entry point to the application. In this layer, it's possible to implement additional functionalities such as authentication, cache, or security (SSL, for example).

The API gateway must also be replicated and load balanced to avoid becoming the "single point of failure" application. Thus, it must not become monolithic and group all calls to microservices. You can separate API gateways using functional domains or platforms (desktop, web, mobile). It will balance the load and give the correct data to provide to the client.

You can delegate authentication or cache implementations to the gateway, thereby avoiding specific implementations for each microservice. It improves implementation times by reducing the load, makes it easier to write and read microservices code by outsourcing certain portions, and facilitates scalability. This is because these implementations are "centralized" and therefore easier to scale, and microservices that refrain from these implementations are easier to maintain and scale.

An API gateway, if implemented correctly, yields many benefits. There are still risks, such as becoming a centralized point of failure. The API gateway may become a bottleneck. However, solutions such as AWS API Gateway, Azure API Management for Azure, or Ocelot for .Net Core. are available to solve these kinds of problems.

This post was written by Talha Khalid. Talha is a full-stack developer and data scientist who loves to make the cold and hard topics exciting and easy to understand.

Application Security Audit: An In-Depth Guide

StackHawk

The cost of security incidents is increasing, and this cost is now the third-largest IT spend after salaries and hardware. Despite this, the average time to detect a security breach is massive.

Security audits are an essential part of a secure application development life cycle. A thorough application security audit can help you determine if your apps are vulnerable to various security threats and identify the areas requiring future investments.

This blog post discusses what an application security audit is and how you can use it to improve the security of your applications.

An application security audit is a comprehensive assessment of the security posture of an application or system

Defining an Application Security Audit

An application security audit is a comprehensive assessment of the security posture of an application or system. It's typically performed by an external organization or third-party company and identifies security risks and vulnerabilities.

The audit can be performed manually or automatically, and generally includes the following:

Identifying security risks
Assessing the likelihood and impact of those risks
Making recommendations for mitigating or eliminating the risks

The goal of an application security audit is to provide a clear and concise report that you can use to improve your application's overall security.

Why Conduct App Security Audits?

Regular application security audits are essential to ensure your applications' security and integrity. By auditing your applications, you can identify and fix any security vulnerabilities.

Additionally, regular audits can help prevent future security issues by identifying potential risks and measures to mitigate them.

While some organizations may view application security audits as a costly and time-consuming endeavor, the truth is that they can save you a lot of money and headaches in the long run. By catching security issues early on, you can avoid the costly damages resulting from a data breach or other security incident.

Also, regular audits can help improve your organization's overall security posture and give you peace of mind knowing that your applications are as secure as possible.

Companies can define the scope in terms of features, functionality, or data

How to Perform an App Security Audit

Security auditors perform several steps to carry out a comprehensive application security audit. Firstly, it is essential to understand the scope of the audit and what specific areas need to be covered.

Companies can define the scope in terms of features, functionality, or data. For example, if the audit aims to identify all potential security vulnerabilities, the scope would be the entire application. However, you can limit the scope to the security of a particular feature or functionality.

Once you've determined the scope of the audit, the next step is gathering information about the application, including any security-related information and information about the application's environment. That means reviewing the source code, documentation, and other relevant materials. The auditor might also interview developers and administrators.

Next, the auditor identifies potential security risks. This includes threats to data and systems' confidentiality, integrity, and availability.

The final stage of the process is to report on the audit findings and recommend ways to remediate any identified vulnerabilities. This report should be clear and concise and be provided to the relevant parties promptly.

Types of Application Security Audits

Auditors can perform a variety of application security audits, and the most appropriate type(s) for a particular company will depend on several factors. Some of the most common types of application security audits include:

Security vulnerability assessments: These audits focus on identifying security vulnerabilities and risks. They can be conducted using various methods, including manual code reviews, automated scanning tools, and penetration testing.
Configuration audits: These audits focus on assessing the security configuration of systems and applications. They can help to identify weak and insecure settings that could leave an organization open to attack.
Access control audits: These audits focus on assessing the effectiveness of an organization's access control mechanisms. They can help to identify areas where access control is weak or could be improved.
Logging and monitoring audit: These audits focus on assessing an organization's logging and monitoring capabilities. They can help to identify gaps in coverage that could leave an organization vulnerable to attack.

What to Look for When Choosing an Application Security Audit Vendor

If you're responsible for implementing security in your organization, you've likely realized that it's not as straightforward as it seems. New threats emerge daily, and you need to update your security measures accordingly.

As a result, you need to hire a third-party application security audit company that can help you stay ahead of the curve. However, choosing the right vendor without proper knowledge will be challenging. You need to keep three things in mind while selecting an application security audit vendor: the vendor's security capabilities, approach to security, and experience.

You should expect a vendor to have the expertise to analyze your application and determine where the security issues are. They should also be clear on their weaknesses, which is where experience comes in.

You'll want to look at prior audits to get an idea of the problems they identified and their proposed fixes. Choosing a vendor with experience working with your type of application is essential.

If you are using a specific technology, you must ensure that the audit vendor is familiar with it. The audit should include a report that gives you details on where the security issues are, along with a recommendation on how to fix them. It should also have an action plan that will be implemented to fix the issues.

Common Issues Found During a Security Audit

As an application security company, we've seen countless examples of vulnerabilities that could have been prevented. Below are the top three vulnerabilities we come across in our day-to-day work.

The first vulnerability is the lack of input validation. Input validation ensures that the data provided by a user or client is validated for type, length, format, and values. Developers should use input validation to ensure that only valid data is passed to your application. This helps to prevent unexpected behavior. Input validation is one of the most critical aspects of application security.

The second type is broken access control issues, a broader class. There are many types of broken access control vulnerabilities, but they all essentially involve circumventing the controls that are in place to restrict access to data or resources. Common examples include accessing data that is not supposed to be accessible and elevating privileges to gain access to sensitive data or resources.

The other common type of vulnerability is SSRF, which stands for server-side request forgery. This type of attack occurs when an attacker tricks a server into making a request to another server on behalf of the attacker. This can be used to exploit internal systems that are not intended to be accessible from the outside and bypass firewalls and other security measures. In some cases, SSRF can also be used to perform denial-of-service attacks.

Application security is much larger than most people realize, so it's essential to understand how to audit your apps properly

Conclusion

Application security is much larger than most people realize, so it's essential to understand how to audit your apps properly. You can make your application and data more secure by avoiding these common application security mistakes. Each of these mistakes makes it easy for a hacker to exploit your application and access data they wouldn't be able to otherwise.

It is a good practice to perform security audits regularly. Check for vulnerabilities and ensure that your application does not allow any unwanted access or needs to be potential grounds for cyber-attacks.

We hope you've enjoyed learning about the application security audits. If you would like to learn more about application security audits or would like to book a demo, please email us or check out this link.

How to Establish an Application Security Policy

StackHawk

The reality is that if you have a business online today, there's a big chance that malicious hackers are targeting your applications. This can cause a lot of damage and cost not only in terms of money but reputation too. In order to address this issue, you need to start by having an application security policy in place.

The application security policy should be a part of your overall security policy. If you have not yet established one, you should read on to learn how to establish an application security policy.

In this blog post, we'll look at what you need to include in a well-constructed security policy and how you can establish one.

What Is an Application Security Policy?

An application security policy is a document that outlines the security measures that should be taken when developing, deploying, and managing an application.

A security policy is one of the most essential elements of an organization's overall security program. Whether it's a formal or informal policy, a security policy provides the framework for developing and implementing a cohesive set of security controls.

The policy should be tailored to the organization's specific needs and should be reviewed and updated regularly. An application security policy is an integral part of an organization's overall security strategy and can help to protect its applications from attack.

As mentioned, the policy should cover all aspects of application security, from development to deployment and maintenance. It should also address how to handle security incidents and vulnerabilities. The policy should specify the acceptable levels of risk for the application and should outline the procedures for managing and responding to security incidents.

In addition, an application security policy provides the framework for understanding the level of security an organization can provide to its business and customers.

Why Is an Application Security Policy Vital for an Organization?

As our lives move increasingly online, data security has become a top priority for organizations of all sizes. A comprehensive application security policy helps to protect an organization's data and systems from unauthorized access and malicious attacks. By defining clear security procedures and controls, an organization can ensure that its data is appropriately protected at all times.

An application security policy is vital for an organization because it helps to ensure its data's confidentiality, integrity, and availability. In the event of a security or data breach, an organization can use its security policy to help determine the cause of the breach and take steps to prevent it from happening again.

As mentioned, by having a well-defined security policy in place, an organization can help to protect its data and systems from unauthorized access and malicious attacks. A policy can also help companies avoid costly penalties for noncompliance, like the kind that could come from running afoul of the Payment Card Industry Data Security Standard (PCI DSS).

Also read: How Security-Based Development Should Work

Five Critical Elements of an Application Security Policy

Having a solid application security policy is critical to the success of any organization. It provides a map for all employees to follow when developing and maintaining applications.

If an organization doesn't have an application security policy in place, all of its applications are at risk of being hacked. To help you create an effective application security policy, we've outlined five key elements that must be included:

There should be a clear and concise statement of the organization's commitment to security. This commitment should be backed up by senior management and should be communicated to all employees.
The policy should identify the specific security risks that the organization is facing and how the organization will manage these risks.
The policy should outline the security measures that the organization will put in place to protect their data and systems.
It should identify the roles and responsibilities of those within the organization who are responsible for security.
The security policy should also outline the procedures for reporting and responding to security incidents and all communication channels.

At last, it should clearly define what constitutes a security breach and the consequences for employees who violate the policy.

How to Create an Application Security Policy

There is no one-size-fits-all answer to this question. Rather, the best way to create an application security policy will vary depending on your organization's specific needs. However, there are some general principles that you should keep in mind when creating your policy.

First, you need to identify the assets that need to be protected and the risks they face. This will help you to determine the appropriate security measures that you need to put in place.

Next, you must establish clear rules and procedures for how your employees handle sensitive data and access sensitive systems. This will help you to minimize the risk of data breaches and other security incidents.

Finally, you must ensure that your policy is regularly reviewed and updated to reflect changes in your organization's security posture. This will help to ensure that your policy remains effective over time.

Who Develops an Application Security Policy?

Many business owners, who have some experience in IT, believe that the development of a security policy is the responsibility of their IT department.

This is not quite the case. A security policy is developed by a team of security professionals with experience designing and implementing security measures for software applications.

The security team is responsible for ensuring that all applications used by the organization are secure and meet the required security standards. In some cases, the organization may outsource the development of an application security policy to a third-party vendor. It may also involve other stakeholders, such as the application development team, business owners, and operational staff.

Challenges of Creating and Implementing an Application Security Policy

It's no secret that developing and implementing an application security policy can be challenging. There are several factors you have to consider, including the type of applications you use, the sensitivity of the data you process, and the organization's overall security posture.

Perhaps the most significant challenge is making sure that you properly secure all your applications. This can be daunting, particularly in large organizations with hundreds or even thousands of applications.

Another challenge is ensuring that the security policy is comprehensive and covers all potential security risks. This requires a thorough understanding of the risks and how they can be mitigated.

Also, it can be challenging to get buy-in from all stakeholders, as some may see security as a hindrance to productivity. For example, some employees may feel that security increases the time it takes to complete a task. Thus, it's vital to address these concerns and ensure that your team understands why security is important and how it can benefit productivity.

Conclusion

Application security is a hot topic right now. Cybersecurity experts now advise that companies must develop and enforce strict application security policies to prevent malicious attacks.

These policies are a significant first step toward securing your organization's applications. Still, it's also essential to ensure that your employees are aware of these policies and understand the importance of adhering to these controls.

Thanks for taking the time to read our guide on establishing an application security policy. We hope you feel more confident about your approach to application security. If you would like to learn more about our products and services, don't hesitate to get in touch with us anytime.

A Developer's Guide to Fixing The 6 Most Common API Vulnerabilities

StackHawk

When it comes to the adoption of Application Programming Interfaces, or APIs, the technology is growing rapidly and has been for quite some time. More businesses are turning to APIs for their internal and external operations, truly making them a core component of day-to-day business. It's encouraging to see the rise in API adoption, but it's also crucial to understand the security implications of that growth and how you can mitigate them. Along with adoption, API security vulnerabilities will continue to rise, and organizations must be prepared.

This post will examine serious API security vulnerabilities and how to protect yourself.

What Is an API Vulnerability?

An API vulnerability is a type of security flaw that allows attackers to access sensitive data or execute other malicious actions. API vulnerabilities can occur when an API is poorly designed or implemented or inadequately secured.

Hackers can exploit these API vulnerabilities to launch different attacks, such as denial-of-service attacks, or to gain access to confidential information. Overall, a vulnerability is an opening for someone to take advantage of with malicious intent, and each can compromise API security in various ways.

Why Is API Security Important?

API security is essential because it helps to protect data and prevent unauthorized access to resources. Organizations can achieve API security through various means, such as authentication, authorization, and encryption. By implementing API security measures, companies can ensure that only authorized users can access their data and resources.

Additionally, API security can help to protect data from being intercepted or modified by unauthorized users. The most comprehensive list of potential API security issues is the OWASP API Security Top 10, a derivative of the OWASP Top 10 Vulnerabilities many are likely familiar with.

OWASP API Security Top 10

The OWASP API Security Top 10 is a comprehensive list of the most critical API security risks compiled by security experts worldwide. This list serves as a standard guideline for businesses and developers to understand and mitigate the risks associated with API security. The OWASP API Security Top 10, updated in 2023, includes:

Broken Object Level Authorization (BOLA): This occurs when an API does not properly enforce access controls, allowing attackers to manipulate object IDs to gain unauthorized access to sensitive data.
Broken User Authentication: Weak authentication mechanisms can allow attackers to compromise user accounts and gain unauthorized access.
Broken Object Property Level Authorization (BOPLA): This vulnerability arises when APIs fail to enforce proper authorization checks on object properties, leading to unauthorized access or modification.
Unrestricted Resource Consumption: APIs that do not limit resource usage can be exploited to consume excessive resources, leading to denial-of-service (DoS) attacks.
Broken Function Level Authorization (BFLA): This occurs when APIs do not properly enforce authorization checks at the function level, allowing attackers to execute unauthorized functions.
Unrestricted Access to Sensitive Business Flows: APIs that expose sensitive business processes without proper access controls can be exploited to gain unauthorized access to critical operations.
Server Side Request Forgery (SSRF): This vulnerability allows attackers to manipulate server-side requests, potentially accessing internal systems and sensitive data.
Security Misconfiguration: Inadequate security configurations can leave APIs vulnerable to various attacks, including data breaches and unauthorized access.
Improper Inventory Management: Failing to manage and secure all deployed API versions can lead to the exploitation of deprecated or insecure APIs.
Unsafe Composition of APIs: Combining multiple APIs without proper security measures can introduce vulnerabilities and increase the attack surface.

Understanding these top 10 API security risks is essential for protecting sensitive data and preventing unauthorized access to your API. Based on this info, how would we mitigate some of these vulnerabilities? Let's take a look at this next.

Mitigating API Security Vulnerabilities

Mitigating API security vulnerabilities requires a combination of awareness, education, and the implementation of robust security protocols. Here are some strategies to help mitigate API security vulnerabilities:

Implement Strong Authentication and Authorization Mechanisms: Ensure that only authorized users can access your API using strong authentication methods, such as multi-factor authentication and comprehensive authorization checks.
Use an API Gateway: An API gateway can manage and monitor API traffic, enforce security policies, and provide a centralized point for implementing security measures.
Implement Rate Limiting and Throttling: Prevent denial-of-service (DoS) attacks and brute force attacks by limiting the number of API requests that can be made per unit of time.
Use Encryption: Protect sensitive data in transit and at rest by using encryption protocols such as HTTPS and TLS.
Regularly Test and Scan for API Vulnerabilities: Conduct regular security testing and scanning to identify and fix potential security flaws in your APIs. This includes using tools like SAST and DAST platforms.
Implement Object-Level Authorization Checks: Ensure that proper authorization checks are in place to prevent unauthorized access to sensitive data at the object level.
Use Secure Protocols for Communication: Always use secure communication protocols, such as HTTPS and TLS, to protect data from being intercepted or tampered with.
Monitor API Traffic and Logs: Continuously monitor API traffic and logs to detect and promptly respond to security incidents.

By implementing these strategies, you can significantly reduce the risk of API security vulnerabilities and protect your sensitive data.

How Can an API Be Insecure?

As alluded to in our OWASP API Top 10 coverage above, An API can be insecure in several ways. Let's discuss some of the most common ways in detail, including the particulars on how to protect against these common API vulnerabilities.

1. Broken Access Control

Access control in APIs is a critical security measure that controls who can access data and functionality within an API. However, if access control is not implemented correctly, it can leave APIs vulnerable to attack.

One type of attack that can exploit poor access control is known as a broken access control attack. This type of attack occurs when a hacker/attacker can bypass the security measures in place and gain unauthorized access to data or functionality.

To protect against broken access control attacks, it's essential to implement proper access control measures in your API. This includes appropriately implementing authentication and authorization checks. It's also essential to keep your access control measures up to date as new vulnerabilities are discovered.

To protect against broken access control attacks, it's essential to implement proper access control measures in your API.

2. Broken Authentication Issues

Since APIs rely on authentication to grant access to data and resources, any authentication process flaw can jeopardize the API’s security. Broken authentication is a significant security issue in APIs, as it can allow attackers to access data and resources they should not have access to.

Compromised authentication tokens can allow attackers to impersonate legitimate users, leading to potential data breaches and unauthorized access.

There are many ways in which authentication can be broken, such as using weak or easily guessed passwords, failing to validate user cookies, or lacking JWT expiration properly.

There are a few things that you can do to prevent broken authentication issues in your APIs:

Implement proper authentication and session management controls—this includes using strong passwords, encrypting sensitive data, and using session timeouts.
Restrict access to your API to only those who need it—this can be done using an access control list or an API key.
Monitor access to your API and look for suspicious activity—this can help you to detect and stop attacks before they happen.

3. Injection Attacks

Injection attacks are a type of attack where code (malicious) is injected into a system. This can be done through a variety of means but is often done through APIs. Injection attacks can gain access to sensitive data, execute unwanted actions, or cause a denial-of-service condition.

In injection attacks, the attacker takes advantage of the fact that the API accepts input from untrusted sources. By injecting malicious code into the API through user input, the attacker can cause the API to execute unwanted actions or return sensitive data that the attacker can then use to gain access to the system.

To protect against injection attacks, validating all input received through an API is essential. This includes ensuring that the input is of the expected type, size, and format. Additionally, it’s essential to escape any special characters used in injection attacks. By taking these precautions, it’s possible to reduce the risk of injection attacks significantly.

4. Excessive Data Exposure

The proliferation of APIs has increased data exposure risks as more sensitive data is being shared via these interfaces. In many cases, API developers do not adequately secure their APIs, leading to data leaks and other security issues.

This type of data leak can have severe consequences for the individuals whose data has been exposed and the organization responsible for the API.

To avoid these risks, organizations should carefully control access to their APIs, ensure that only authorized parties can access the data, and protect sensitive files and directories.

5. Lack of Rate Limiting

Rate limiting is a way to control the rate at which an API processes requests.

Lack of rate limiting in APIs can lead to excessive requests that can overload the system and cause it to fail. This can result in a loss of data and service outages. Rate limiting is critical to API design and should be implemented to ensure the system's stability.

By limiting the number of incoming requests that can be made per unit of time, rate limiting can help prevent resource overuse, improve performance, and reduce the risk of denial-of-service attacks.

Rate limiting is a way to control the rate at which an API processes requests.

6. Insecure Direct Object Reference

Insecure direct object reference (IDOR) is a type of security vulnerability that occurs when an application references an object using a direct reference. A hacker/attacker can exploit this to gain access to sensitive data or perform unauthorized actions.

For example, a GET request is used to fetch user details such as name, card details, family member details, etc., and the API relies on the user ID, which the client sends as a parameter. If the user ID is guessable or can be brute forced, an attacker can change the user ID in the URL and fetch the sensitive details of other users.

To prevent this attack, it's essential to never reference an object using a direct reference. Instead, applications should use indirect references that are not guessable or predictable. For example, an application might use a UUID to reference an object.

How Do I Check API Vulnerabilities?

API vulnerabilities can be difficult to track down and fix. However, there are a few ways you can check for them.

One way is to use a web application security scanner such as the StackHawk DAST scanner. These tools can help you identify common vulnerabilities, such as SQL injection.

Another way to check for API vulnerabilities is to review your code. This can be done manually or with a static code analysis tool. Reviewing your code can help you find potential security flaws, such as incorrect input validation or the insecure storage of sensitive data.

Maintaining an accurate inventory of API versions is crucial to prevent security issues, particularly managing deprecated API versions. This is made even easier when using StackHawk's API Discovery feature to find and catalog all existing versions of your APIs.

Finally, you can also monitor your API for unusual activity. This can help you detect potential attacks, such as denial-of-service attacks. Monitoring your API can also help you identify unauthorized access to sensitive data.

Conclusion

An API is a gateway to access information and data. A vulnerable API can lead to a breach of data and unauthorized access. An API can be susceptible for several reasons—design, coding, configuration, etc.

This post focused on API security vulnerabilities and the steps you can take to prevent them. We hope you enjoyed it and found it helpful. For more information on how StackHawk can help you find and fix the most common API vulnerabilities, sign up for a free trial to get started on your own, or contact our team of API security experts for more info.

Importance of Web Application Security: Three Benefits

StackHawk

A lot of businesses have web applications that cater to the needs of customers, and those applications are very important to the success of those businesses. Software developers have to produce high-quality applications to meet the demands of the business’s users. The world has become more and more digital, technology is evolving quickly, and security threats are evolving just as fast.

In this post, you'll learn the importance of web application security. We'll also cover the risks and consequences of poor web application security.

What Is Web Application Security?

Web application security is a set of processes that protect your web applications against malicious attacks. It takes a collective effort from people, processes, and technology to protect web applications.

By people, I don't just mean personnel in charge of security, because web apps pass through developers, then DevOps engineers, then CI/CD before moving to production, and finally, users. Every team in the development cycle needs to understand web application security so they can spot vulnerabilities in an application.

Most companies have a web application security policy, which is a set of rules every person involved in the development cycle must follow to produce secure applications.

Risks of Poor Web Application Security

Web application security isn't something to be complacent about. You must consider it at every step in the development process, not just at the end, before deployment. You must make sure your technology can avert modern cyberattacks. Poor web application security will leave your application vulnerable and exposed for hackers to exploit.

The Open Web Application Security Project (OWASP) publishes a list of the top ten security risks, which they update yearly. Below are the top risks for the year 2021.

Broken Access Control

Broken access control is when an attacker bypasses a system’s permissions. The access control should enforce the security policy, and if it fails to do so, an attacker can access restricted information they’re not authorized to access. They can also make modifications to, and even delete this information.

Cryptographic Failures

Cryptography is the study of secure communications techniques, where the communication is encrypted so that only the sender and receiver of a message can view the content of the message. A cryptographic failure occurs when an attacker gains access to sensitive data, due to a weak encryption (i.e., cryptographic) algorithm.

Injection

An attacker can inject malicious code into your web application, making the interpreter execute unintended commands. Applications that do not have a good filter to detect hostile data, or a way to validate data input by users, are vulnerable to injection attacks. A common example is SQL injection.

Insecure Design

When a developer focuses on design and architectural flaws, and neglects to implement security controls throughout the development process of a web application, we call this an insecure design. This can happen when a developer fails to understand the level of security their application requires.

Security Misconfiguration

Attackers can gain easy access into your system when security controls are not properly configured. According to OWASP, security misconfiguration can result from a number of things, that include installing unnecessary features, enabling default passwords, error messages that contain too much information, disabling security features, servers with insecure directives, and out-of-date software.

Vulnerable and Outdated Components

You have to be aware of the current versions of all system components, and make timely upgrades. The developers also have to test the compatibility of any upgrade, and regularly check for vulnerabilities.

Identification and Authentication Failures

Almost every app requires users to verify their identity in some way. If you do not implement authentication in your web application, your system is vulnerable. An attacker can gain access to usernames and passwords.

Security Logging and Monitoring Failures

If you don't actively monitor your application, you cannot identify vulnerabilities. Your application should be able to detect threats and attacks in real time. Also, security logging constitutes sensitive data, and should be hidden from users.

Server-Side Request Forgery (SSRF)

OWASP describes SSRF as a flaw that occurs when an application fetches a remote resource without validating the URL. An attacker can force the server to send information to an unexpected destination.

These are the top ten risks you face when you practice poor web application security. Now that you know about the risks, let's look at some of the consequences.

Consequences of Poor Web Application Security

The most obvious consequence of poor web application security is the exposure of sensitive data. Sensitive data can include anything from passwords and usernames to bank card details, medical records, and financial records.

An attacker who gains access to this data can use the information to commit fraud, including identity theft. If you can't protect your web application, you run the risk of suffering financial loss, and losing the confidence of the users who trust you with keeping their data safe.

Security issues can delay the deployment of an application, especially if you do testing late in the development cycle. Delays will put pressure on developers if there's a delivery time constraint, and can tempt them to release an application with flaws that attackers can exploit.

Benefits of Web Application Security

As already established, the internet plays a big part in the success of many businesses, big and small. If you can get the security of your applications right, there are several benefits.

Reduced Risk of Attacks

By having good web application security, you can identify areas of vulnerability and fix them before attackers have a chance to exploit them. To reduce the risks, you can hire a dedicated security team and set up a web application firewall.

Boost in Confidence

A benefit of good web application security is the gain in confidence of the users if you protect their data well. Having a secure system instills confidence in the business that hired you, and also in your developers. It also means your reputation remains intact.

No Business Disruptions

Identifying security risks early in the deployment cycle will ensure that deployment happens when it's supposed to happen. Delays in identifying vulnerabilities will only lead to disruptions, which can then cascade into more severe issues.

Final Thoughts: the Importance of Web Application Security

Security should never be an afterthought at the end of development. Every team member that plays a part in the development of a web application must have a high level of education on web application security. Identifying vulnerabilities early enough will reduce the risk of attackers gaining access to your web application. OWASP provides a list of security risks you should guard against by following good practices. Loss of revenue, exposing sensitive information, loss of user and customer confidence, and a ruined reputation are some of the consequences of having poor web application security.

This post was written by Oscar Jite-Orimiono. Oscar has a B.Eng in mechanical engineering, but now he’s a self-taught frontend web developer and technical writer. His skills include HTML, CSS, and JavaScript(Vanilla and jQuery). He builds websites with a focus on them being user-friendly, responsive, and having pleasing aesthetics. He’s also interested in data science, Python, and SQL.

API Security Risks: 6 to Be Aware of and How to Prevent Them

StackHawk

Today, the world runs on technology powered by robust data ecosystems connected via APIs. Our mobile and desktop apps, IoT-enabled smart devices, financial institutions, and more all run on the tech that's powered by APIs under the hood.

Humankind has witnessed that the more popular and widely accepted tech gets, the bigger of a target it becomes for security attacks. New kinds of attacks and their respective remedies appear constantly. In order to keep their applications and APIs secure, organizations need to keep up with API security best practices.

What Are the Common API Security Risks?

The Open Web Application Security Project, known as the OWASP Foundation, is a nonprofit foundation that works to improve the security of software. OWASP maintains a list of the top 10 API security risks to which security researchers across the globe contribute. These are said to be industry benchmarks when it comes to API security. Just by mitigating these security risks, organizations can reduce attack vectors significantly. Let's walk through some of these common API security risks to ensure a more secure application architecture.

1. Broken Object Level Authorization

Broken Object Level Authorization, or BOLA, is a lack of resource ownership validation before serving requests. This means that the server doesn't validate the relationship of ownership between the client and the requested object. That may lead to anyone being able to access anything.

For instance, in an e-commerce application, you might have a "View My Orders" section that runs off a GET API that lists all the order IDs associated with your user ID. Then there's another API that serves detailed information based on an order ID without further checking whether the requested resource belongs to the client or not.

This can be easily exploited by trying multiple combinations of the order IDs and "getting lucky," by finding that the underlying table in the database is set up in a way that auto increments the order IDs while creating.

Now, suppose the attacker has access to any order ID. In that case, they can go up or down that range and potentially get personally identifiable information off those incremental order IDs, such as the contact or delivery address for an order.

The solution is to always check if the client is authorized to access the requested resource(s) or not. There's no better or simpler way to put it.

2. Broken User Authentication

Generally, all our application's pages sit behind either a login or a public sign up page. This presents these access methods as a target that attackers can exploit. Some common authentication issues include weak password policy, sending passwords in clear text to the server, trusting that all users are humans (no CAPTCHA), and weak or no encryption.

Companies can mitigate login or sign up vulnerability risks by implementing brute-force-resistant mechanisms such as rate limiting, CAPTCHA, stronger password policies, account inactivity timers, etc., to ensure the users are authenticated at all times.

OWASP provides a single reference point of authentication guidelines documented in their Authentication Cheat Sheet.

3. Excessive Data Exposure

Excessive data exposure is, in effect, where data is picked off the database and sent to the client without any sensitivity filtering or fine access control within a RESTful API.

This vulnerability can be easily identified and caught by requesting to fetch data off your server and examining the API responses. These responses will always consist of data or metadata that the client isn't supposed to be looking at.

The solution here is to get a good grasp on the application's business logic. That will allow you to only send data required by the client and nothing else. This, at scale, also decreases the size of your API responses, leading to lower bandwidth costs.

4. Lack of Resources & Rate Limiting

Lack of rate limiting means that your server will keep accepting requests until it just can't anymore. Not imposing a limit on how many requests can be sent to a server makes it vulnerable to Denial-of-Service (DoS) attacks. In DoS attacks, the server can be flooded with too many requests. Eventually, this could lead to the server breaking down and causing an outage, thus a loss of actual and potential revenue.

This vulnerability can be easily identified by hitting any server with a barrage of requests (aka load testing) and checking if it breaks down.

There are several ways to enforce rate limiting on a server. Here's a detailed blog for readers who want to dive deeper into a Node.js implementation.

5. Broken Function Level Authorization

Broken function level authorization is where administrative actions are available via REST APIs but lack authorization on the function level. Essentially, the system does not recognize the difference between admin users and regular users. Therefore, it'll grant access to everyone and allow administrative actions to be run.

Attackers could quickly identify this by exploiting the API URL's general REST API principles and nomenclature. Merely changing the GET user's API method to PATCH or DELETE might give regular users destructive capability without authorization.

A straightforward solution is to block all actions as a default config. Then you open up actions to certain users or user types only when required. With administrative actions, it's much better when admin users are not able to use them compared to regular users also being able to use them.

6. SQL Injection

Many applications build SQL queries based on user input—for example, text input for string comparison. Let's look at an example of an order cancellation query. In this case, an order ID is expected to be sent by the client as a query parameter in the Delete API URL itself. Here, the following query template is expecting the order ID:

const query = `DELETE FROM Orders WHERE OrderId = ${req.query.orderId};`;

This could let attackers have direct access to your database where they can, instead of the order ID, call:

DELETE /api/orders?orderId=123%20OR%201%3D1

This will ultimately build the following SQL query:

DELETE FROM Orders WHERE OrderId = 123 OR 1=1;

The SQL query generated above is valid and thus will delete all rows from the Orders table since OR 1=1 is always True.

The solution could be strict parameter checking for the URL query. However, the rule of thumb is to never trust user input. Always sanitize user input with well-recognized input sanitization libraries. That will ensure that, if you're expecting the orderId in the route's query params to be an integer, it's nothing except that. Many libraries have been made to solve this problem. You could go with any of the popular ones actively maintained by the open-source community.

The rule of thumb is to never trust user input.

API Security Risks: Conclusion

As ever-evolving as security risks are, best practices and industry standards can ensure the security of APIs and overall applications. Multiple of these security risks are pretty simple to exploit, yet also simple to understand and mitigate. Developing applications with a security-first mindset is highly advised, as it saves teams redundant effort.

Safeguarding APIs against some of these common security risks will drastically reduce attack vectors and surface area provided to attackers. Most of the discussed security risks are easy to exploit but can be protected against to keep your organization safe.

How Does StackHawk Work?

Matt Tanner

In a world of rapidly evolving security threats, ensuring robust security across various platforms — from single-page applications to multiple types of APIs — has become one of the biggest concerns for businesses worldwide. Developers, especially, are acutely aware of this mounting pressure. For years, developers have been told to adopt secure coding practices, reinforce server security, and vigilantly monitor for signs of compromised applications.

As technology advances, the focus on applying security best practices has shifted from merely relying on human vigilance to adopting more sophisticated and automated methods. These advances in security technologies have enabled developers to preempt security breaches instead of simply reacting to them. One significant advancement was the adoption of Static Application Security Testing (SAST). SAST has been instrumental in identifying potential vulnerabilities in code dependencies, enabling developers to address these issues before they reach production. However, SAST primarily scrutinizes the static aspect of the code, leaving a critical area unaddressed: runtime vulnerabilities.

This gap in security testing is precisely where Dynamic Application Security Testing (DAST) platforms like StackHawk excel in improving an organization's security posture. DAST addresses SAST's blind spots by identifying vulnerabilities that only surface when the application runs. Often overlooked in the development phase, these vulnerabilities can pose significant risks if exploited once the application hits production. In this blog, we will look at the basics of DAST and then dive deep into the inner workings of StackHawk and how it works.

What is Dynamic Application Security Testing (DAST)?

Dynamic Application Security Testing, commonly known as DAST, is an automated process that tests applications in their running state to identify security vulnerabilities. Unlike Static Application Security Testing (SAST), which analyzes the status source code of an application, DAST interacts with an application in its running state, simulating the actions of a potential attacker. With DAST tools, developers can detect issues that manifest at runtime, such as injection attacks, cross-site scripting (XSS), and other vulnerabilities that can only be exploited when an application runs.

With traditional web applications, DAST tools explore and interact with an application through the front end without requiring access to the underlying source code. This method enables them to identify security flaws from the perspective of an unauthorized or unauthenticated user. As a result, the tests executed by a DAST tool are particularly effective in uncovering network and application-layer vulnerabilities that external attackers could exploit. The process involves sending various inputs to the application, analyzing the outputs, and monitoring the application's behavior to detect potential vulnerabilities. Regarding APIs, DAST tools can look at the input and output of an endpoint to determine if a security vulnerability is present. Of course, not all DAST tools support testing all types of APIs (or APIs in general). StackHawk supports testing REST, GraphQL, SOAP, and gRPC APIs, the particulars of which we will cover later.

The strength of DAST lies in its ability to assess an application in its operational environment, which includes not just the application itself but also its interaction with other systems and databases. This real-world, black-box nature of testing with DAST makes it a crucial component of a comprehensive security strategy, particularly for web applications and APIs where user interaction is a constant factor. Once an application is running, implementing a DAST solution can ensure that applications are functionally sound and secure from external threats.

What is StackHawk?

StackHawk is a dynamic application security testing tool built to help developers find, triage, and fix security bugs in their applications. StackHawk is a modern DAST tool that focuses on enabling the “shift-left” methodology for application security aimed at moving testing into the developer's hands and earlier in the SDLC. As a DAST platform, instead of scanning static code, StackHawk finds bugs that you or your team may have written into the code by testing a running version of your application. Running StackHawk can be done in a local development environment or your CI/CD pipeline, something StackHawk is explicitly built for.

StackHawk also allows you to dig deeper than legacy DAST tools by pushing forward advanced API and Microservice testing features. Since StackHawk scans a running version of your application, it finds the vulnerabilities available to an outside attacker. Since StackHawk only reports vulnerabilities that can be actively exploited, the platform reports fewer false positives. Less unnecessary noise keeps developers focused on tackling the vulnerabilities attackers can exploit once the application hits production servers.

Why use StackHawk?

Dynamic Application Security Testing (DAST) is crucial in uncovering many security vulnerabilities within applications. StackHawk, as a modern DAST tool, excels in finding critical vulnerabilities that expose themselves at runtime. Especially with its automated integration in CI/CD pipelines. This ensures that vulnerabilities are identified and resolved before they reach production.

StackHawk's DAST capabilities extend to a broad spectrum of vulnerabilities, including but not limited to:

SQL Injection
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)
And a wide range of other vulnerabilities typically found in the OWASP Top 10 list

Unlike traditional DAST solutions, StackHawk is designed for modern application architectures, enabling exhaustive testing across various API types such as REST, SOAP, GraphQL, and gRPC. This comprehensive approach ensures that your applications and APIs are thoroughly tested for vulnerabilities.

How does StackHawk work?

StackHawk contains 2 components which power the overall platform. The first is HawkScan Scanner, which scans your application paths and finds vulnerabilities. This process can run anywhere in your delivery pipeline. The second component is the StackHawkPlatform itself. The StackHawk Platform is where the results from the HawkScan Scanner are collected and analyzed. This is also where developers can communicate and track findings to ensure a resolution. Let’s dig a bit further into how each component works.

Scan Discovery

To find vulnerabilities in the running application or API, HawkScan Scanner needs to run against your code in a running application. Developers can get started by using Docker or Hawk CLI to start the process. This can be done by using docker or by using Hawk CLI to start the process.

Scan Discovery, facilitated through HawkScan, is the first step in finding vulnerabilities. The process determines which paths and endpoints StackHawk should test by crawling your web application and API routes. To find meaningful vulnerabilities, HawkScan will try to discover parts of your site, intercepting the request & response HTTP payloads as it navigates your web application. This can be configured and fine-tuned under the hawk.spider section of the stackhawk.yml file you’ll use to configure StackHawk.

A few different scans which can be performed by the HawkScan scanner. Let’s go over some of the more popular options below.

Base Spider

The base spider is a web crawler that is used to discover application routes and will be appropriate for most traditional web applications. The spider discovers the pages of your application by finding URLs through responses containing a Content-Type of 'text/html'. Through these URLs, the spider then does a breadth-first search on those paths until it has reached all accessible pages.

Custom Scan Discovery

Another way for HawkScan to discover your web application is by using other familiar tools to provide commands or generate web traffic. For example, some popular tools to use with HawkScan are Postman, Cypress, or an HTTP Proxy. While using these tools to generate traffic, HawkScan will intercept and scan the generated traffic for vulnerabilities. This feature is an excellent way for security teams to combine their favorite software testing dev tools and customize their HawkScan experience.

Scan Discovery for APIs

Regarding APIs, StackHawk and HawkScan can use a few different methods depending on your API technology. Of course, specific API routes and actions will also be picked up by the previously mentioned scan discovery methods. However, StackHawk offers a few different ways to ensure your APIs are tested entirely and accurately, no matter the technology you are using. Let’s take a look at the specifics below.

Open API Spec

Those familiar with OpenAPI/Swagger Specifications will be happy to know that they can be used within HawkScan to deliver a faster and more conclusive scan. HawkScan will use the contents of a provided OpenAPI spec to improve the quality of a scan in two ways:

Pre-seeding the sitemap using the routes defined in the OpenAPI spec. This can be used to complement any crawled routes or can be used instead of app spidering altogether.
Using defined inputs to routes in the spec to inform how to communicate with the web application and gather clues on how to better attack endpoints.

GraphQL Introspection endpoint

HawkScan is also able to support GraphQL APIs as well. This is done through the GraphQL API’s Introspection endpoint. HawkScan is a pioneer for application security testing your GraphQL APIs.

This scan allows Hawkscan to perform an introspection query on a GraphQL app. This introspection query enables HawkScan to generate routes based on available operations. The scanner can be configured to enumerate all known types and input parameters for Query and Mutation together or each type separately.

gRPC Schema Reflection and File Descriptor Sets

For those utilizing gRPC, HawkScan offers specialized support to ensure comprehensive security testing. gRPC, which uses Protocol Buffers and HTTP/2, can seamlessly integrate with HawkScan for detailed security analysis. HawkScan can obtain the gRPC schema through reflection or a file descriptor set. Reflection is recommended since HawkScan can retrieve the schema directly from the running application. HawkScan can use a pre-generated file descriptor set in cases where reflection isn't enabled. Both methods allow HawkScan to create tests based on available gRPC endpoints.

SOAP Web Service WSDL Support

HawkScan extends its capabilities to support SOAP Web Services, leveraging the Web Services Description Language (WSDL). This enables HawkScan to interface accurately with SOAP-based services used in many legacy applications. By parsing the WSDL file, HawkScan can identify the operations, inputs, and outputs defined for the SOAP service. By doing this, StackHawk can ensure that vulnerabilities specific to SOAP implementations, such as XML injection or SOAP action overloading, are effectively identified and addressed.

The Scan Itself

As the discovery process uncovers each path within the application, the scan of the application itself begins. The scan runs asynchronously and as more paths are added to the tree, scans are executed against them to check for vulnerabilities.

The scan itself is quite simple to explain; HawkScan will attempt to identify vulnerabilities by probing for known vulnerabilities against your running application. Vulnerabilities that will be detected by HawkScan can include instances of SQL Injection, Cross-Site Scripting, and Proxy Disclosure. HawkScan will print the scan details to the console as it runs. This will let users know how the scan is progressing, what HawkScan is working on, and potential vulnerabilities the scan uncovers. At the same time, the scanner also streams data to the StackHawk platform, so you can watch your scan status online in real-time.

Tuning the Scan

Developers can fully customize a scan by using different flags in the command used to initiate the scan. Using flags and config tweaks to customize the scan allows StackHawk to run even faster. Much faster.

Tuning can include configuring HawkScan to authenticate to your app, introspecting and scanning GraphQL, reading your app’s OpenAPI specification, and other settings to help StackHawk run quickly and in a more targeted fashion.

You can also use StackHawk Technology Flags to tell HawkScan which technologies your application uses, such as Java, Javascript, and MySQL. This will ensure that StackHawk only runs the applicable tests for the specific technologies used in your application. The scan can run faster without sacrificing effectiveness by excluding tests that do not apply to your technology stack or applications.

Reviewing Findings and Potential Fixes

Once all of the application paths are discovered and scanned for vulnerabilities, users can come to the StackHawk platform to review the findings. The StackHawk platform offers a place for users to review the scan results, and possible fixes, as well as a place to manage each of the findings. Unlike products that find vulnerabilities and leave the developer to find possible solutions, StackHawk gives meaningful insight into potential fixes and shows developers how to resolve the issue right within the platform.

Let’s take a look at a few features within the StackHawk Platform that help teams to create more secure applications and prioritize their security needs.

Findings Management

Once security defects and vulnerabilities have been found in your code, StackHawk allows you to classify each of the findings as False Positive, Risk Accepted, or Send to Jira/Assigned. This can be extremely useful since it gives flexibility to teams to decide which findings are important to fix as soon as possible and which ones can be moved to a later date or sprint.

Using cURL for Easy Debugging and Fixes

Part of StackHawk’s mission is to make security more accessible to engineers. As part of this initiative, being able to recreate the bug or vulnerability in your application is of highly important. Sometimes, this can be complex, forcing users to recreate a command or call an API that they are unfamiliar with. Even worse, they may not know how to correct the command to create the exact condition needed to expose the vulnerability in the code.

StackHawk allows users to generate a cURL command with the correct HTTP verb, headers, and data fields to recreate the potential attack. By running this curl command and running the application in debug mode in your IDE, you can step through the requests to identify where the issue lies within your code. With this, developers can quickly fix the vulnerability and ensure their application is secure.

Using StackHawk with a SAST Platform

On top of the DAST capabilities of StackHawk, some users may also want to integrate with SAST platforms, such as Snyk or GitHub. Using a SAST platform alongside StackHawk will allow findings to be linked between the SAST tool and the entry in StackHawk. Engineers can use both platforms to ensure that their code is secure from all angles.

The SAST platform scans through the code statically, looking for patterns which may denote a potential vulnerability. These findings could indicate that the code does in fact contain a security defect. The vulnerability can then also be validated with a StackHawk HawkScan. Correlating the two scan result helps to show that issues are exploitable and accessible (via StackHawk) and where the issue lies in the code (via the SAST platform). Combining these findings helps prioritize issues for developers and enables them to confirm, reproduce, and fix them quickly and efficiently.

Using StackHawk to Secure APIs

As the use of APIs continues to explode, they are becoming a more popular attack vector that developers should be aware of and actively defend against. Users of DAST may only think of it in terms of testing a web application versus applying it to their suite of APIs. With StackHawk, APIs are front and center of the DAST experience. As mentioned in the sections above, StackHawk can quickly determine your API endpoints by uploading an Open API Specification or, if using GraphQL, an introspection endpoint, for example. On top of REST and GraphQL support, StackHawk also supports testing SOAP and gRPC APIs.

When StackHawk tests an API, the endpoint is put through its paces with a meticulous set of tests to expose any vulnerabilities it may reveal. StackHawk allows users to dial in their particular API setup so that tests can be tailored and customized on top of the platform's default set of tests. When a vulnerability is detected, users can see the result in a report which contains the request, response, and any evidence that a vulnerability exists. On top of this, developers are also supplied with fix guides to show developers how to remedy the exploit quickly.

Try it out!

Now that you have an idea of how StackHawk works and the advantage it can bring to your application security, sign up today to try it out for yourself. Whether you’re looking to bring DAST to your Traditional Web App, Single Page Application, or even your APIs, StackHawk is the most efficient way for engineers to bring security scans directly into your organization's CI/CD pipeline. Make API and application security a default priority in your team's development lifecycle.

StackHawk + GitHub: A Saga in Shift-Left Security

Brandon Ward

With all the requirements of modern development, few may be as important as ensuring the security of your application is maintained. Keeping the state of your application’s security visible and up-to-date should be one of the highest priorities for your engineering team.

To aid with this, StackHawk provides an Official GitHub App capable of doing just that! With a small amount of configuration, you will be able to receive commit statuses and pull request comments that immediately inform you about the state of your application security.

To the Left

Part of the shift-left mindset is to leverage tools and processes that can provide critical information sooner in the development lifecycle. By correlating the evolution of source code with the results of your dynamic application security testing (DAST), the hope is to find issues sooner and to make them more visible in primary development workflows.

Commit statuses provide you greater peace of mind in knowing that your HawkScan has completed, so that you can be alerted quickly if your application scans detect vulnerabilities or happen to break from new code changes. Detailed results are never too far away either, as there is a link straight to the StackHawk platform with the full scan details on each commit status.

Pull request comments include high-level summaries of found application vulnerabilities in context with the code changes, so an increase in vulnerabilities can be seen immediately in the pull request and can be squashed before ever making it to the main development branch.

By committing to communicate important information as early as possible in your development process, your team is equipped to make decisions and execute on the facts faster than ever before. The ultimate goal is to empower engineers to iterate faster, confident that they are upholding the security requirements of the application.

Putting it in Action

StackHawk is a dynamic application security testing tool (DAST), meaning HawkScan tests the running application and not the source code. Therefore, linking to the source code requires a little help.

Because we encourage HawkScan usage as part of your CI/CD pipeline, it isn’t a stretch for us to assume that you are incrementally scanning new commits and branches all the time. By leveraging the assumption that scans are running in a CI/CD pipeline, we are able to provide a few configuration options that allow your pipeline to explain how this scan maps back to your source code’s history.

To enable this feature, you will need to have the StackHawk GitHub App installed, with GitHub repositories connected to StackHawk applications for all repositories that you want to enable commit statuses and PR comments for.

Then, you’ll need to adjust this configuration snippet for your `stackhawk.yml` and CI/CD provider, so that your CI/CD pipeline can explicitly tell StackHawk where this scan belongs in your Git history.

```yml tags: - name: _STACKHAWK_GIT_COMMIT_SHA value: ${YOUR_CICD_PROVIDED_ENV_VAR_SHA:} - name: _STACKHAWK_GIT_BRANCH value: ${YOUR_CICD_PROVIDED_ENV_VAR_BRANCH:} ```

After specifying these tags, your next successful scan on a pull request will include a high-level overview of any DAST findings.

For a complete how-to, check out the official documentation.

👀 See it in Action

[Video]

That’s a Wrap

With the modern era of software development, security is everyone’s responsibility, but that does not make it any easier. In fact, it’s harder than ever before.

The best thing we can do to keep our applications safe is equip our processes with the tools to provide us the details we need to make the most informed decisions that we can. Choosing tools that enable us to automatically and quickly gather the right information, and use them to their fullest potential is one of our most important responsibilities.

Application Security Risks: 4 Types and How to Fix Them

StackHawk

If an app has a vulnerability that could allow an attacker to access a user's data, it could put them at risk of identity theft or data loss. As the security industry continues to grow, more people realize the importance of application testing.

Over the past few years, many have referred to application security as a cybersecurity issue. It usually refers to issues such as malicious software and phishing attacks. However, one of the most critical applications is in software development.

There are a lot of misunderstandings about what security testing is and how it can be done. This article aims to explain four different application security risks and how you can address them.

Application security is a set of techniques, policies, and technologies that ensure applications' confidentiality, authenticity, integrity, and availability.

What Is Application Security?

Application security is a set of techniques, policies, and technologies that ensure applications' confidentiality, authenticity, integrity, and availability. It also protects against fraud and malicious manipulation. You may have heard that app security is a ticking time bomb—and it's true!

But software developers can take care of these four types of application security risks:

1. Injection flaws

2. Logic and design flaws

3. Authentication and authorization flaws

4. Exposure of sensitive information

Injection Flaws

Injection flaws are where a hacker could inject malicious code into an application. The hacker accomplishes this by exploiting security vulnerabilities in the web browser or tampering with the input data passed to an application.

The most common exploit is SQL injection. Most security checks are done through the user-entered data as SQL statements (SELECT, UPDATE, REPLACE and INSERT). If a hacker can control the data, they might manipulate the database. The second form of injection exists in web services. This happens when an attacker sends a malicious XML document to an Axis2 service endpoint and causes it to execute arbitrary code or disclose information from or to another system or user they are not authorized to access.

Logic and Design Flaws

A design or logic flaw is an error that allows an attacker to access or control an application's functionality. An attacker can perform unauthorized actions or access sensitive data by exploiting these flaws.

The most common design and logic flaw is the insecure direct object reference. This vulnerability allows an attacker to access an object's data if they can change its reference. For instance, if an attacker changes the URL of a file, they can access its sensitive information.

Another common design and logic flaw is the insecure storage of cryptographic keys. An attacker can exploit this vulnerability to access the stored keys in an insecure location. For instance, if an attacker has access to the keys, they can decrypt or alter the data of an authorized user. They can perform unauthorized actions, access sensitive data, or bypass security controls. Organizations should regularly test and adopt secure design principles in their applications to minimize the risk of these flaws.

Authentication and Authorization Flaws

Authentication gives you access to a resource after you provide the correct credentials, while authorization grants you access to a resource depending on your permission levels. Now, a flaw means you are not limiting access to sensitive data based on any logic. For example, an application with sensitive data (bank accounts, home addresses) should contain strong authentication mechanisms like multifactor authentication.

Exposure of Sensitive Information

Unauthorized disclosure of information may occur through a buffer overflow vulnerability when an attacker submits a carefully constructed but malicious data request that overrides memory locations used to store sensitive information (such as cookie values). Data loss also occurs when an attacker gains access via a network or security breach and can send malicious requests with unintended codes.

Buffer overflows are often combined with injection vulnerabilities to gain control of resources (such as creating new threads) or execute commands without authorization. Most languages and all major frameworks contain some built-in protection against buffer overflows, but they can exist in any programming language. Some methods of protection may require protocol changes.

How Can I Fix My Application Security Risks?

Some say that willful security risks are not a problem. But even if you employ all the best possible safeguards and build a bullet-proof application, it's still possible to make errors. So, how do you defend against this type of risk? Here are five things to do to eliminate these types of errors.

A robust authentication mechanism can provide them with an additional layer of security by requiring a second factor, such as a code from a hardware token.

1. Use Strong Authentication Mechanisms

One of the most important factors that organizations should consider when implementing strong authentication is ensuring that their applications are secure. A robust authentication mechanism can provide them with an additional layer of security by requiring a second factor, such as a code from a hardware token. This type of security can make it harder for an attacker to access their app. Even if an attacker can access an app using a username and password, they still could not login without having the second factor.

Various types of strong authentication mechanisms can be used for your app, and they all have their own level of security to help protect it from attacks.

2. Use Secure Coding Principles and Design Patterns

Secure coding techniques can eliminate a wide variety of application security risks. One typical example is to make sure that every time the app receives user input, it must be validated first. If this is not done, an attacker could insert malicious software or keyboard data that would allow their code to run.

In addition, to protect against a brute force attack, the app should have multiple passwords that are required for logging in.

3. Testing

Be sure to test your code at every stage, not just during your first release into production. This prevents attackers from discovering your insecure parts through debugging or testing for other vulnerabilities in managed applications. It also makes it easier to identify errors when you update your code later. Failing to test all parts of your code can cause a wide variety of security vulnerabilities.

1. Broken or poorly coded interfaces

2. Unsecure authentication and session management, such as cookies and storage (to hold user IDs and encrypted passwords, for example)

3. Insufficient encryption for sensitive data

4. Weakly protected password systems

5. Insufficient authorization checks on sensitive data

4. Perform Penetration Testing and Vulnerability Assessment

This allows you to spot insecure parts of your application, test their operations under attack conditions, and fix them. Penetration testing is an effective way to identify new vulnerabilities while your app is in development. It offers some assurance that the app will work as expected once you release it to the public.

5. Encryption

It's also important to use covered input fields, especially those that multiple users can reuse. This will make it much more difficult for attackers to succeed in their attacks because they will have to ensure that each input field does not get reused by another user. It may take some time for an attacker to find new inputs, but since most injection flaws are common and easy to overlook, this safeguard is critical.

Conclusion

Every day, hackers exploit vulnerabilities in applications to steal data or hack networks. And every day, application developers are scrambling to plug these security gaps before they trap their users with an application they can’t use. But there’s hope: a diversity of automated tools like StackHawk allow developers to easily identify potential application flaws and work around them by optimizing the code.

This post was written by Mercy Kibet. Mercy is a full-stack developer with a knack for learning and writing about new and intriguing tech stacks.

API Security: OWASP's Top 10 Vulnerabilities Explained

StackHawk

Every organization of any size has a security policy that outlines what developers should do to ensure their applications are safe. If a company has good API security policies, this can go a long way in protecting user data and/or stopping attacks from outside sources. For example, using tokens to authenticate users protects against brute force attacks.

This post explains API security and OWASP Top 10 vulnerabilities. This list defines what we think are the biggest risks in web applications today and serves as a starting point for building secure applications and encouraging secure coding practices. The post will also give suggestions on how you can mitigate each risk.

Before we cover OWASP's top 10 vulnerabilities, let's first understand what API security is.

What Is API Security?

API security is the implementation of security controls between our back ends and their respective consumers to prevent unauthorized access to data, systems, or accounts.

There are specific components that constitute API security:

Authentication: This is the process through which users provide proof of identity before being granted access to specific resources.
Authorization: This is how you grant users access to specific resources via authentication. You check authorization during every interaction between a user and your service.
Session management: We identify a user's session by associating it with their request. This can include cookies, devices, IP addresses, and other identifiers.

The Open Web Application Security Project (OWASP) is a nonprofit organization committed to improving software security.

What Is OWASP?

The Open Web Application Security Project (OWASP) is a nonprofit organization committed to improving software security. OWASP's goal is to increase awareness of software security—thus helping individuals and organizations make informed decisions about true software security risks.

The OWASP definition of API security is "the protection of APIs from unauthorized access, use, or modification."

Although API security is important, it is not foolproof. There are many ways for attackers to bypass security measures and access data or API functionality.

Now let's look at the top 10 vulnerabilities as listed by OWASP.

OWASP's Top 10 Vulnerabilities Explained

OWASP has identified various security vulnerabilities affecting a company's web applications. OWASP released its list of the top vulnerabilities that need to be addressed to better understand developers' daily problems. The list of vulnerabilities is based on the contributions of security professionals and businesses.

The 10 critical areas from OWASP's 2021 list where most problems stem from are as follows:

1. Broken access control

2. Cryptographic failures

3. Injection attacks and command injection attacks

4. Insecure design

5. Security misconfiguration

6. Vulnerable and outdated components

7. Identification and authentication failures

8. Software and data integrity failures

9. Security logging and monitoring failures

10. Server-side request forgery

1. Broken Access Control

This vulnerability allows attackers to get information or perform actions restricted to specific users. There are several ways in which this can happen.

One example of broken access control is when an application doesn't properly restrict access to sensitive data. For example, given an API endpoint api/address/user/user_id that lists user addresses based on their user_ids, then anyone with access to that data can view or modify it (i.e., by trying different user_ids especially if the IDs were auto-incremented).

Mitigation

Don't allow your API users to "guess" the authentication mechanism you're using. Avoid hardcoded tokens, secrets, and keys. Try to use something more secure such as OAuth 2.0 tokens and cookies with credentials encrypted (hashed).

Use role-based authorization—this way, you can manage which users have access to which functionality and ensure no third-party application can access your system.

2. Cryptographic Failures

Cryptography vulnerability occurs when your application fails to properly use cryptographic functions such as hashing, encryption, and digital signatures (public key or symmetric). This common mistake allows hackers to perform many attacks, such as spoofing.

Spoofing is the first step attackers take when they get access to your system. They'll create a domain and then try to capture the user's authentication credentials. If they succeed, they'll try to do the same thing in other applications that use the same mechanism.

Mitigation

Use proper cryptography. Ideally, use a public key infrastructure (PKI) and ensure you have a certificate for each user. This will solve the problem of spoofing because if the domain is trusted, the user won't accept any certificate presented by someone else.

Don't store sensitive data in clear text. If you need to get data from one system to another, use an XMLHttpRequest (or, even better, HttpWebRequest), encrypt it, and then send it via HTTPS.

3. Injection Attacks and Command Injection Attacks

These attacks are about running malicious code through unexpected input methods (e.g., overloading a variable with external input) or entering malicious code into a legitimate website. These types of attacks are the most common in web applications. They could cause data theft or session hijacking, leading to impersonation or privilege escalation attacks.

Mitigation

1. Limit input through allowlisting where applicable.

2. Use output encoding techniques for untrusted data.

3. Enable parametrized queries for databases.

4. Insecure Design

This is an area where developers aren't incorporating application security into their system's design, or it isn't done correctly when they do. When designing a new framework, you should always strive to integrate security throughout your application as much as possible. Otherwise, you'll repeat yourself throughout your app's design and maintenance phases.

Mitigation

1. Have security-critical functions as methods on the class that handles them rather than inside controllers.

2. Never give more data to a third-party company than you have access to; have policies in place for dealing with it if you do.

This vulnerability involves the improper configuration of security mechanisms that can be publicly accessible or even of an internal network that could cause unauthorized access to sensitive data.

5. Security Misconfiguration

This vulnerability involves the improper configuration of security mechanisms that can be publicly accessible or even of an internal network that could cause unauthorized access to sensitive data. This could include setting up a firewall incorrectly, allowing hackers to enter and cause harm from within the firewall itself.

Mitigation

1. Correctly configure all security mechanisms.

2. Check for and fix any weak or missing security mechanisms.

3. Review the configuration of applicable libraries to ensure good design practices.

4. Ensure that you set up your firewalls correctly according to the policies you set for your application.

6. Vulnerable and Outdated Components

This area includes the use of vulnerable components, such as those that have known security weaknesses. In addition, an out-of-date component can lead to a higher risk of attack since it might not be up to date with security patches. When relying on third-party software or components, you can't control their internal structures. But you can ensure you update them according to the latest updates, making your application less risky.

Mitigation

1. Update all components according to their release dates.

2. Upgrade all components every six months or as security patches are released.

3. Test the components in your system to ensure they are secure before you install them in production.

7. Identification and Authentication Failures

We relate this vulnerability to failure to authenticate users or access credentials properly. It could include password weaknesses, weak session identifiers, weak session tokens, replay attacks, or weak passwords used for authentication.

Mitigation

1. Use sessions that are not vulnerable to replay attacks.

2. Use strong session identifiers.

3. Use authentication tokens for web apps.

4. Ensure that cookies aren't vulnerable to injection attacks (e.g., do not set unsafe values or sensitive information in cookies themselves).

8. Software and Data Integrity Failures

This area involves software vulnerabilities like buffer overflow attacks, memory corruption problems, and data integrity issues, such as weak checksums or lack of digital signatures and hashing algorithms that can be easily exploited—even by a casual hacker who is interested in your data but performing no actual "hacking."

Mitigation

1. Ensure that the code uses secure checksums to detect and prevent tampering.

2. Verify integrity checks are being performed.

3. Enable encryption of sensitive data to protect it from prying eyes.

9. Security Logging and Monitoring Failures

This vulnerability is about failing to include security logs in your application or not monitoring them—thus causing a lack of historical data that could help figure out how an attack/exploit happened. Logging provides critical information to the developers and security experts who can work on recreating the events that caused such damage from a policy or technical perspective.

Mitigation

1. Enable security logging in your application and monitor it regularly.

2. Ensure the logs include data vital to the system's integrity.

3. Use log correlation tools to correlate events across distributed applications or components.

4. If debugging is required, ensure you're not compromising privacy information in the logs themselves.

This could cause unauthorized actions by attackers after they have a victim click on a malicious link or submit a web form.

10. Server-Side Request Forgery

This area has two problems: The first is the failure to implement a secure request forgery response. And the second is not using a secure HTTP protocol when sending requests among systems. This could cause unauthorized actions by attackers after they have a victim click on a malicious link or submit a web form.

Mitigation

1. Proactively check outgoing requests and block any that look suspicious.

2. Ensure you include no sensitive information in headers that can carry out additional attacks.

Conclusion

The OWASP Top 10 is a valuable resource that helps you build secure web applications by identifying and addressing the most common vulnerabilities in your systems. Following the guidelines above—and integrating API security testing using StackHawk—minimizes your application's exposure to security risks and reduces the likelihood of falling prey to an attack.

This post was written by Mercy Kibet. Mercy is a full-stack developer with a knack for learning and writing about new and intriguing tech stacks.

8 API Security Best Practices Your Org Needs

StackHawk

Developers and designers create applications that aim to provide the best possible functionality. These applications may also include internationalization (i18n), localization, and internationalization. Developers may choose not to include security measures or business logic in their applications because it's unnecessary for the platform. However, many security measures are left unchecked because the business requirements cannot justify them. Security professionals and developers must work together to build secure applications resistant to the most common attacks. Any API vulnerability, no matter how big or small can pose a massive security risk. A DDoS attack and the leaking of sensitive information are just a few of the disastrous results of a successful API attack. As API traffic continually increases, so does the need for securing APIs.

This post covers the eight API security best practices that your organization needs to implement to properly secure your APIs.

API Security Best Practices

Before implementing an API, the system's security must be built into the design and implementation. You should do this in a way that's consistent with best practices. Proper security measures can help prevent unauthorized access to an organization's data and services.

Below are the eight best practices when securing an API.

Prioritization of security
Strong authentication and authorization
Encryption
API gateways
Rate limiting
Secure logging
Security testing
Swagger & OpenAPI

Prioritization of Security

The first step when protecting your business from cyberattacks is prioritizing security over other aspects of development like time to market or expansion. Investing more time in identifying vulnerabilities before an attack protects you from a breach and reduces the operational cost of fixing it afterward.

Strong Authentication and Authorization

When developing an API, your application should use a mechanism to authenticate users and ensure they're authorized to access the requested data. One of the easiest ways to introduce robust authentication and authorization to your APIs is through an API management platform. Many different API management platforms exist, with each of them supporting different authentication and authorization mechanisms. API management can also offer other benefits beyond security as well. For instance, when a user tries to sign in to your application, they'll provide their username and password on the login page and click 'Login.' This will trigger an API call from your application server to the user information service, which can be stored in a database or somewhere else entirely to validate whether the username and password provided by the client are valid. The response from this API request should include an access token that the client should store for later use. There are many ways to store this token and ensure you allow the user to access the data, including storing it on their local machine for convenience or with a third-party service. Click here for more information about authorization.

Encryption

Encryption helps protect your data from unauthorized access. The most common type of encryption is symmetric encryption, which uses a single key to encrypt and decrypt data. This type of encryption is relatively weak because it's easy for attackers to crack. The attacker can decrypt the encrypted data using a similar encryption key. Asymmetric encryption is a more potent type of encryption, which uses two keys: a public key that anyone can use and a private key that only the owner can use. This type of encryption is more secure since the private key is not easily accessible. This is the best practice when encrypting data in transit to prevent unauthorized access and ensure that sensitive information remains confidential.

Another essential security best practice is ensuring you encrypt all data accessed by your API before sending it to the server and storing it on your database. Properly configuring your service and performing proper error handling can also help with protecting data from unauthorized access.

API Gateways

Managing data from an API can be tricky if you're using APIs, depending on the user's method, such as when a customer wants to update their order through an API or a web browser. When the API communicates with a user, another layer of security should prevent an attacker from taking advantage of the API to impersonate a user and manipulate data. One way to do this is to introduce an API gateway between your client and your server as an additional layer of protection. This specific type of API acts as a proxy between the client and server, separating the API from other applications so you can change them without affecting other systems. Many of the security best practices discussed in this article can be directly implemented through an API gateway or API management platform.

Rate Limiting

By introducing rate limiting to your API endpoint, you control the number of requests allowed per second and IP address restrictions to ensure that the client devices connecting to your API are valid. Rate limiting is a best security practice that can prevent brute force attacks and DoS attacks.

This pattern will ensure that your APIs can adequately scale and handle large amounts of data while preventing unauthorized access and ensuring data remains confidential. It will also allow your APIs to support many users without overwhelming your servers.

Secure Logging

To prevent unauthorized access and ensure you correctly handle errors, log all API requests so they cannot be altered or manipulated. The logs should provide secure storage for the data, preventing unauthorized access and protecting against the conversion of data into executable code that could be used for malicious purposes.

Security Testing

Security testing is software testing that, as the name implies, checks for potential vulnerabilities. The main goal of API security testing is to identify any flaws that hackers could exploit and cause harm to data and users. This can involve checking for malicious code, potential loopholes, and backdoors.

Below are the different security types.

SCA stands for static code analysis, which scans through the source code with pre-compiled versions of applications that are often not executable on the target machine.

SAST, or static application security testing, will examine source code or compiled code where you use IAST, or insecure application security testing, with dynamic analysis techniques such as fuzzing to find bugs or errors in web applications.

DAST refers to dynamic application security testing. It uses monitoring tools to generate a model of the tested application and then runs the application's logic against this compiled model to find security problems. You execute the code without a target system, however. Fuzzing may produce false positives, but you can use it as an initial first check.

SAST testing can be time-consuming, depending on the size and quality of the source code or compiled code base. Still, it can uncover vulnerabilities that other types of security testing cannot. SAST is typically based on vulnerability patterns and known attack vectors.

DAST, IAST, and SCA are a few examples of security testing. It's also necessary to test applications you might deploy into production sooner rather than later.

Swagger and OpenAPI

Two tools that can help improve the security of an API are OpenAPI and Swagger. These tools can create and manage specifications for an API. Having the proper documentation and security measures can help prevent unauthorized access to an organization's data and services.

One of the essential advantages of using OpenAPI and Swagger is that they ensure you properly document the API specifications. They can also help you improve communication between the security and development teams. They can additionally make it easier for organizations to identify and prevent security vulnerabilities in their APIs.

Conclusion

Security is one of the paramount aspects of any company or organization. Adopting these API security best practices in your development lifecycle is the best way to ensure your company remains secure. Implementing these practices can be one of the best ways to guard your organization against the vulnerabilities outlined in the OWASP API Security Top 10. However, you need tools in your arsenal to reinforce that. Tools like StackHawk can test your API for any vulnerabilities, and thanks to its triage mechanisms, you can automate your application's security.

Learn more

Read on to see how StackHawk’s CSO, Scott Gerlach talks about “Shift Left” being more than just a buzzword here.
Check out why Omdia’s On the Radar report highlights StackHawk as an “interesting alternative to most other DAST tools” here.
Getting started with StackHawk? Check out Advice and Answers from the amazing StackHawk team here.

Announcing Deeper API Security Test Coverage

Lauren Nagel

When it comes to testing software in general, you want to make sure you have sufficient coverage. When it comes to security testing, that coverage becomes even more important because malicious players bank on you missing something. When you’re security testing your APIs you want to make sure you hit every path, cover every test case, and use the right test data so you don’t get blocked on an email check or during a checkout scenario with an invalid credit card number.

With StackHawk’s Deeper API Security Testing release, we’re giving you three amazing new sets of functionality that ensure your APIs are thoroughly tested and secure. From getting started quickly using existing test tools and resources, ensuring our scanner has valid test data for your use cases, to creating your own custom test scripts to cover the most specific of scenarios, we’re proud to announce these new capabilities:

Custom Scan Discovery
Custom Test Data for REST APIs
Custom Test Scripts

I’m going to give you a quick overview of each new feature (because I’m a Product Manager and that’s what we do), but StackHawk is a devtool, so I will let the amazing developers who worked so hard on these powerful capabilities give you all the details in their own words. Make sure to click through to their blog posts as well!

Custom Scan Discovery - Why reinvent the wheel?

As a dev-first API security test tool, StackHawk has always recommended using OpenAPI definitions as the gold standard for guiding our scanner. But, we understand that not everyone has this level of documentation OR maybe you’ve just already invested in a test script tool that you’d like to reuse.

With Custom Scan Discovery, you can configure the scanner to use your existing Postman Collections, Cypress test scripts, or another test script via a curl command to get started scanning quickly and easily, no API specs required! We’ll even use existing test data from those scripts when we encounter data inputs. Learn more about Custom Scan Discovery and how to get started scanning your app from Sam in his blog post, Customized and Configurable Scan Discovery, or check out the StackHawk docs.

Custom Test Data for REST APIs - Hackers don’t stop at an email address input field and neither should your test

When you’re testing any applications, test cases require different test data. Sometimes you need valid data to move forward down a path, sometimes erroneous data, sometimes random data. Each might help you discover different error cases or potential vulnerabilities. And inputting incorrect data could stop your test altogether, leaving your app insufficiently tested.

With Custom Test Data for REST APIs, you are now in charge of the test data HawkScan uses. We’ll not only let you configure your test data, we’ll help you figure out where you need it, and give you a FAKER library when necessary. And as I mentioned above, if you’re using an existing test script with Custom Scan Discovery, we’ll go ahead and use that test data so you don’t have to configure two tools. Austin has all the details in his deep dive on Custom Test Data for Rest APIs, or go straight to the docs here.

Custom Test Scripts - Every app is its own special snowflake

StackHawk’s scanner is built on the well-known ZAP library for security vulnerabilities, so we’re already checking for a lot, but sometimes you need to cover a specific use case for your app or organization. Business logic, sensitive data, and privacy laws all require custom tests. Additionally, if you want to use existing custom tests from the ZAP library, you can add those to your StackHawk scans too.

Tenancy checks or Broken Function Level Auth are now within your grasp with just a little scripting. Dana even gives you an example in her blog, Scanning with Custom Test Scripts. After registering your scripts, they’ll be added to your scans and we’ll show you any alerts in the StackHawk platform alongside your other results. View details, triage, or assign alerts to devs for custom test alerts just like you would for any other vulnerabilities found by StackHawk. Check out the StackHawk docs for more details as well.

“We’re far from the shallows now…”

Lady Gaga hasn’t confirmed yet, but our CISO Scott Gerlach and myself will be demoing and discussing Deeper API Security Testing in our webinar on 9/28.

Watch the recording here!

All this functionality is available now, so if you’re already a customer we hope you dive deeper into your API security testing right away!

Want to get started with StackHawk? We have an On Demand Demo and Free 14-day Enterprise trial available at www.stackhawk.com. Ready to talk to someone and see StackHawk in action, contact us sales@stackhawk.com.

Custom Test Data for REST APIs

Austin Pearigen

Why is this new feature important?

In the real world, the parameters defined in a REST API are meant to represent real data, in other words, usernames, asset IDs, query strings, and so on. Using real data for these parameters solicits more realistic logic from your application, and exercises more branches of your code.

For instance, in a password update flow in a REST API, if a username or ID is provided that does not exist within the context of the application, a simple 404 should be returned on the resource lookup, and none of the actual password reset code will be invoked. However, if the resource can be found, all of the password reset code will be exercised with the parameters provided.

This is where Hawkscan’s ‘Custom Test Data for REST APIs’ comes into the picture! This new feature allows users to configure values they want to use in a scan for each defined parameter. For each parameter in a scan, a list of values can be provided, and one of the values will be chosen randomly for each path that parameter belongs to.

How is this new feature configured?

To supply custom values for a REST API’s parameters, some configuration is necessary in the `stackhawk.yml` file. Under the `app.openApiConf` section of the configuration, a new array field called “customVariables” is available, which represents a list of fields and corresponding lists of values for each key. The key represents the parameter in your OpenAPI definition, and HawkScan uses the list of values to choose one on the fly when scanning a REST API. By default, the scanner will NOT use these custom values for DELETE methods. This default behavior is because HawkScan is running real malicious attacks against your application, so to err on the side of safety, DELETEs will not use any custom variables, even if a list of values is provided for that parameter.

To override this default behavior and use custom values for ALL HTTP methods, simply set `includeAllMethods` to true. If you want more control over which methods will use custom values, you can set exactly which methods to use with the `includedMethods` list.

Note: `includeAllMethods` defaults to false, but if set to true, the `includedMethods` will be ignored if provided.

I don’t want to supply my own data, but I do want more realistic values.

Sometimes existing data isn’t always necessary and properly formatted values will still be more effective than previous HawkScan default values. Leveraging the Faker library, HawkScan can now generate more realistic data for a REST API using the `format` field on the OpenAPI definition. By using this field along with the type and other schema constraints, HawkScan can generate data that matches your schema on the fly.

For instance, if a request has a phone number as one of its parameters where the type is a string and the format is phone, an actual phone number can be generated rather than a default value string that has no relation to a phone number. Or if a path uses an integer ID parameter but the schema constrains the number to integers from 1-100, HawkScan will generate a random number within this range. To use these faker values, the `fakerEnabled` parameter in the openApiConf section of the `stackhawk.yml` file should be set to `true`. When enabled, HawkScan generates a realistic value for any parameters that have a format or constraints set and don’t have custom values also supplied in the `stackhawk.yml` file.

My spec doesn’t have formats, but I still want to use more realistic values.

If your API definition isn’t quite up to date with formats for each field, you can still leverage the `customVariables` section of the `stackhawk.yml` config file to inject Faker values into your scan. To do this, add a custom variable for each parameter you want to use Faker values for, and in the list of possible values, include `$faker:{format}` as a value.

For example, if the API definition includes an email in a request body, but the definition only defines that parameter as a type string and does not additionally supply the format, then in the `stackhawk.yml` file you can include `$faker:email` as a value for that parameter, and a realistic email will be generated for each path that parameter appears in.

📺 Watch a Quick Demo

[Video]

Customized and Configurable Scan Discovery

Sam Volin

HawkScan provides multiple mechanisms to discover running web applications. Security and software development teams can combine forces and accomplish more in their software development pipeline by using the Spidering, HAR file, Seed Path, or Custom Scan Discovery mechanisms.

Discovering an application by spidering pages

During the Active Scan portion of HawkScan's operation, it will actively attack and attempt to replicate known software vulnerabilities against any paths your application exposes. Understanding what endpoints your web application exposes is fundamental to how HawkScan operates.

After HawkScan has started and configured behavior, but before the Active Scan, it will begin the Scan Discovery phase, finding the paths of your web application by "spidering" them. This process will follow the URLs and relative paths found on each application/HTML page in a breadth-first search(BFS) pattern. Starting from the scanned `app.host`, this pattern will look for URLs within the same origin of your host (read: the application you’re scanning), and perform a Passive Scan on the response, checking for any direct evidence of known vulnerabilities on a separate thread, before adding the path to the site tree for reuse during the Active Scan.

This behavior is what happens by default when you run HawkScan. HawkScan caps spidering at 2 minutes by default, so this part of the scan won't take forever like some other AppSec tools. HawkScan also supports scanning from an OpenAPI specification file, Or a GraphQL introspection endpoint, or even a Soap WSDL file to find attackable paths into your API.

All of these aspects of the scan are entirely configurable within the stackhawk.yml file as well, by the way:

Discovering an Application with HAR Files

A HAR (HTTP Archive) file is a log of a web browser's interaction with a website. It stands for HTTP Archive format and is designed to store and share collected data about network requests, responses, and other performance-related information. HAR files capture details such as URLs, headers, cookies, timings, and content for each HTTP request made by the browser, which can be leveraged to discover your application.

With HawkScan, you can identify and map the paths of your web application using HAR files. Although we prefer API specifications, HAR files rovide a high level of control and precision in how HawkScan navigates and analyzes your web application making it a better alternative than spidering for scan discovery.

We’ve made the scan discovery process for single-page apps even easier, by allowing you to record HAR files directly from your local machine, providing even greater accuracy. This is extremely helpful for recording authentication to ensure you are testing password-protected routes.

To record a session, use hawk perch start --with-chrome and --with-proxy-info to begin the recording, and hawk perch stop --har-file=<file name> to save your session. You can learn more with hawk perch start --help and hawk perch stop --help.

Discovering an application by telling HawkScan what's what

The web-crawling mechanism to discover a web application is not a silver bullet. It requires a link to be on every page in your web application in some fashion, all starting from your root `app.host`. This scenario won’t work for pages that are unlinked or hidden. If you know exactly what paths in your web application you want HawkScan to visit, tell it explicitly by specifying `.seedPaths` . Providing HawkScan with seedPaths will add these application routes to the internal site tree to be visited later during the Active Scan.

You can read more about HawkScan scan discovery and spidering mechanisms in our sweet documentation.

Customizing HawkScan with your favorite DevTools

This brings us to a cool new feature in HawkScan 2.8.0: Custom Scan Discovery. This feature allows HawkScan to be configured with a specified process command that will run in an environment designed for HawkScan to intercept the web traffic the command generates.

This feature is highly flexible to different environments or build systems, so that advanced developer resources can be reused.

By using this feature security teams can leverage the Postman Collections developers write for testing their API endpoints:

Or they can run their Cypress test suites and feed HawkScan the requests it makes into your web application:

The configuration support for Custom Discovery even works with HawkScan's smart ability to interpolate and safely handle secrets from configuration at runtime. It’s so flexible, you can even invoke a shell and call any arbitrary commands a researcher may need with access to more terminal resources, so security researchers can get into all kinds of shenanigans with HawkScan:

And more! These tools are just the tip of the iceberg. Any devtools that support proxying their web traffic into a separate host, either by the `HTTP_PROXY` environment variable or configuration file, can be used for customized Scan Discovery.

You can learn more about how to succeed with Custom Scan Discovery in our documentation.

Combine them all and discover your whole application

Part of the power of HawkScan is it can use all or none of these spidering, seedpath, and custom discovery mechanisms together. And HawkScan works even better when configured to scan specific API protocols, such as OpenAPI, GraphQL, or Soap. HawkScan has the flexibility and capabilities to adapt to any software environment and support engineering teams in finding vulnerabilities anywhere in a running web application. By giving smarter, straightforward resources to developers and software teams, we hope users can maintain a stronger application security posture as they develop and defend their awesome software.

📺 Watch a Quick Demo

[Video]

Scanning with Custom Test Scripts

Dana White

Congratulations, responsible developer! You’ve shifted left and incorporated HawkScan into your CI/CD pipeline. You are now finding and fixing vulnerabilities before they see the light of day.

But what about vulnerabilities specific to your custom business logic? Your application handles private information and you need to ensure you’re providing protection for that data. Or maybe you want to take advantage of scripts already written by the ZAP community.

Well now you can. StackHawk has released beta support for Custom Test Scripts; active scripts written in JavaScript and run in HawkScan. Custom Test Scripts are a way to create your own vulnerability test. HawkScan will use your custom logic to attack targets in your application and report the results to the StackHawk platform.

Simply write the script, register the script to the StackHawk platform, and add reference to it in your stackhawk.yml configuration file. Now your own custom logic to verify the security of your application can be run on every PR.

Writing your own Custom Test Scripts

One of the more common issues that web applications face is tenancy violation. You have one application serving multiple customers belonging to all different companies and nobody should be seeing data from companies they don’t belong to. But HawkScan doesn’t know that Shirley belongs to Company A and Bob belongs to Company B. It just knows that your application is free and clear of the OWASP Top Ten.

To solve this problem, we can write a naïve algorithm to check for tenancy violation in an active JavaScript Custom Test Script. Your script needs to include the `scanNode()` or the `scan()` function (you could write more, I’m not the boss of you) that should call the `newAlert()` function when an alert is detected. The `scan()` function runs for every parameter in every url on that page whereas the `scanNode()` is run once on the page. The following `scanNode()` function will run with the authentication specified (Shirley’s logged in this time) and will raise an alert when it hits the `/users` endpoint and Bob’s user details are on display.

The scanNode Function

The `scanNode()` function takes two parameters that will be provided by the scanner. The ScriptsActiveScanner and HttpMessage. The `HttpMessage` here is the request sent to the node you’re scanning. Since this is an active scan, I can modify the message to try to attack the node. In the example above, I naïvely append “/users” to each message path and then check if the response contains a user that the authenticated user shouldn’t see. HawkScan will load the script and run it as if it were a built-in plugin. If the function finds a positive response (a tenancy violation), it calls our convenience `alert()` which will create and send the alert to the scanner.

The alert Function

The `newAlert()` function returns a builder for an `Alert` and `raise()` will build the alert and send it to the scanner. In this example, the `PLUGIN_ID` refers to a custom Id, unique to your company and test script. I’ve passed in my evidence index (the spot where I saw the unauthorized content in the response body) and my `HttpMessage` that I manipulated to attack the application. The title, description, and additional parameters you can define, so provide useful feedback for yourself! A full list of available options for alert parameters can be found in the Script Settings Reference.

The StackHawk Platform

If the scan finds an alert based on your custom script, the alert is reflected in the StackHawk platform, along with other vulnerabilities the scan detected.

You can then view the details and triage just like you would with any other finding!

And that’s all you have to do to start writing custom validations for your application!

Examples

Getting Started With Custom Test Scripts

Create a StackHawk account
Read the guide to Getting Started
Contact your sales representative and let them know you want to use Custom Test Scripts
Read the guide to configuring Custom Test Scripts
Script away!

📺 Watch a Quick Demo

[Video]

July Newsletter 2022: GitHub CodeQL Integration, G2 Awards, and more!

Nicole Jones

The Changelog: New Features to KaaKaww About

Our GitHub CodeQL Integration is Now Live! With this new integration, results from StackHawk scans are correlated with GitHub CodeQL findings in a single view to help developers fix high-priority issues faster. When a StackHawk finding is correlated with an existing potential vulnerability in GitHub CodeQL, developers are directed to the line of code where the issue lives, eliminating the guesswork of what to fix first.

See How it Works

🦅 StackHawk Soars the G2 Charts this Summer!

See for Yourself

🍿 StackHawk & GitHub CodeQL In Action

Want to see more of this hawksome integration? Join us on August 16 at 10 AM PT to watch StackHawk's Head of Product, Lauren Nagel, and Solutions Architect, Zachary Conger, reveal how teams can use StackHawk and GitHub CodeQL to remediate critical issues on the fly.

Watch the Recording

Other Happenings: Because We Have to Keep Corporate Busy Somehow

📺 Hawk Talks

Application Security: Going Fast, Safer Webinar
[from the archives] What’s New in DAST + SAST with StackHawk and Semgrep

📽 Virtual Events

August 22: API Security Techstrong Panel

🎟 In-Person Events

August 10-11: BlackHat USA

💼 Jobs @ StackHawk

Senior Solutions Architect

❤️ Give Us Some Love

Share the goodness of developer-first application security. We are always grateful for recommendations and referrals! We’d love for you to share StackHawk with your friends and colleagues, or leave us a review on g2.

June Newsletter 2022: New additions to third-party auth, deeper REST scanning, and more!

Nicole Jones

The Changelog: New Features to KaaKaww About

Third-Party Auth Wizard. Our Auth Wizard now supports configuration for the most popular third-party auth providers including Auth0, Okta, Firebase, and Keycloak. These new additions make it even easier to configure authenticated scanning and get to the good stuff!
Deeper REST Beta. We've gone where no other DAST tool has before— deeper into REST API scanning. Configure StackHawk’s testing inputs to make sure the scanner can reach your API’s most critical logic. That means more robust scans with fewer false positives. Contact beta@stackhawk.com to gain access.
Download Scan Logs. Take control of scan errors by downloading scan logs directly from StackHawk to gain greater visibility into what’s happening when the scanner is running and remediate scan issues quickly.
Slack Updates. We heard you. Slack was a little noisy, so we toned it down by removing the Scan Started notification. Now you can focus on what’s most important— your scan results.

📺 Application Security: Going Faster, Safer

Security is just another component of code quality... but how do you enable developers to find and fix security issues on their own?

💡Here's your first tip: Make security testing part of the CI/CD pipeline

If you're not sure how to get started, watch this on-demand webinar for actionable guidance on helping developers find and fix application and API security issues every time they check in code.

Watch the Recording

Other Happenings: Because We Have to Keep Corporate Busy Somehow

📺 Hawk Talks

📖 Reading Material

📽 Virtual Events

June 30: HasuraCon - Automated GraphQL Application Security Testing Workshop

🎟 In-Person Events

August 10-11: BlackHat USA

💼 Jobs @ StackHawk

Technical UX Writer
Junior Solutions Architect
Senior Solutions Architect

❤️ Give Us Some Love

StackHawk May Newsletter 2022

Nicole Jones

The Changelog: New Features to KaaKaww About

API access to scan data. You asked — we delivered! You can now use our API to pull StackHawk scan results into your favorite aggregator or custom reporting tool.
Seed paths. Some paths in your app or API may be difficult for an application security testing tool to find on its own. With this functionality, you can feed the scanner critical or isolated paths to ensure they are found and scanned every time.
Apple Silicon support. Got the latest and greatest Mac? StackHawk’s Docker-based scanner is now compatible with Apple Silicon Chipsets. And don’t forget, the CLI runs on M1 chips, too.

🎉 StackHawk Raises a Series B Round

ICYMI: We recently secured a new round of funding! This is a huge milestone for StackHawk because it allows us to fuel the growth of our team and continue to deliver on our developer-first approach to application and API security testing.

We are thrilled to have investors like Sapphire, Costanoa Ventures, Foundry Group, and others who believe in our product and support our mission to make application and API security part of continuous software delivery.

🗞 Read the Announcement

🎥 Upcoming Webinar

At the end of the day, application and API security are just another component of code quality — but how do you build scalable processes to support secure code delivery? 🤔

Join us for a webinar with StackHawk's Chief Security Officer, Scott Gerlach, as he shares practical tips to help engineering leaders make security testing part of efficient software delivery.

Watch the Recording

Other Happenings: Because We Have to Keep Corporate Busy Somehow

📺 Hawk Talks

StackHawk & Snyk in Action Webinar
Friday Hacking with HawkScan: Log4Shell Testing
[from the archives] GraphQL Security Testing Technical Workshop

📖 Reading Material

📽 Virtual Events

June 16: JS Nation 2022
June 17-21: React Summit

🎟 In-Person Events

June 4-5: BSidesSF 2022
June 6-9: RSA Conference
June 7-8: CdCon 2022

💼 Jobs @ StackHawk

Technical UX Writer
Junior Solutions Architect
Senior Solutions Architect

❤️ Give Us Some Love

Streamlining Security Tooling in the Developer Workflow with StackHawk and GitHub CodeQL

Joni Klippert

A few weeks ago, Forrester Research released its 2022 State of Application Security Report. This year’s report has big implications for how engineering and security leaders can move forward to make sure that their applications and APIs are more secure.

Forrester once again cited that applications were the most common entry point for external attackers, with software vulnerabilities listed at number one and web application exploits at number three. However, surprisingly, it wasn’t the unknown risks that stuck out in this report. Instead, it was the fact that the way teams are delivering secure software is changing.

For example:

Development teams are now getting involved in purchasing decisions with more security leaders reporting that development teams are both final decision-makers for application security tooling, and budget holders.
Dynamic security testing =! Prod. 87% of organizations plan to implement dynamic security testing (DAST) for applications and APIs in the pre-release delivery cycle.
Security teams are collaborating with engineering to create security champions that ensure that security is considered throughout development.

The message is clear – “shifting left” is no longer a buzzword. Teams are implementing a new model of security and making it work.

Building a Security Approach that Works for Developers

So your organization wants to shift left.

“How do I do that?” is not an uncommon question.

This is a complex topic that requires teams to rethink process, culture, and tooling. But when it comes to tooling decisions, the 2021 Forrester Report on Application Security, gave teams strong guidance on selecting tooling for faster remediations.

The research showed that combining static application security testing (SAST) and dynamic application security testing (DAST) scans results in findings remediated 24.5 days faster than the average, while combining SAST and SCA scans results in remediations taking place six days faster.

This has huge implications for security teams that are now faced with new threats every day. And, it has huge implications for development teams that are pushing breakneck deployment speeds that cannot be slowed down with unplanned rework from security issues. Combining tooling is a win across organizations.

The Need for Unified Tooling

For the engineering leaders we speak with, one concern that often comes up is how to make security tooling work together for a seamless developer experience. Asking developers to click into a different UI for each type of security tool is a non-starter.

If we are implementing security tooling in the development lifecycle, it needs to fit natively where developers are already working and provide developers with a holistic understanding of what needs to be done when security issues arise.

Not only does this equate to big productivity gains for the individual developer who, armed with security information, can fix issues without context switching, it is also hugely beneficial for engineering organizations that can have security included in software delivery without sacrificing velocity.

DAST + SAST: Another Huge Step for Developer Productivity

In April, we delivered our Snyk SAST integration to provide developers with fast fixes to top priority application and API security issues. And today, we are excited to announce our latest SAST integration - GitHub CodeQL.

This integration will correlate StackHawk DAST findings with GitHub CodeQL SAST findings. In doing so, CodeQL users will be able to validate which SAST findings are exploitable and are therefore top priorities for immediate remediation. In the StackHawk platform, users will be directed to the specific line of code they need to address and patch the security issue.

For security users, these integrations will mean no more manual correlation of findings from different tools, creating tickets, and coaching developers through how to find, recreate, and fix the issue. Instead security teams can be strategic leaders, guiding the organization in how to think about risk, and building secure applications from the get go.

For developers who spend an average of 8 hours fixing a single security issue, this equals huge time savings. Developers are notified at the merge if new issues exist and are publicly exploitable. Then they are given exact guidance on how to fix it.

If you are interested in learning more, register for our GitHub CodeQL Webinar slated for August 16 at 10 AM. Our Head of Product, Lauren Nagel, will be walking you through how to deploy and use the new integration to make security testing an efficient part of the developer workflow.

Building Multi-Architecture Docker Images in CICD

Omar Alkhalili

StackHawk has recently released support for arm64 packaged executables and Docker images for the StackHawk scanning engine. This is now standard as part of our scanner pipeline and enables us to support future computer architectures as part of our software build process. Building up our capacity to cross-compile our CLI and Docker images for multiple computer architectures as part of our regular continuous integration demonstrates how seriously we take our automation science.

This blog post describes how we went about supporting builds of our scanner product for the arm64 architecture and outlines the details we had to concern ourselves with and address. Adding this support has allowed our users to run our scanner product on the arm64 architecture. We hope you find this guide useful in implementing multi-architecture builds of your software.

What is the difference between amd64 and arm64 architectures?

Software compiled into executable binaries are built to run for a given architecture. The software architecture describes the instruction set of operations the CPU will perform when executing the machine code. Code compiled for the arm64 architecture could not run on an Intel-based CPU, for example. The ARM standard for software architecture became popular with mobile devices, and the armv8 standard is arm64, which has a 64-bit word length, but can be run in an AArch32 state, which is effectively compatible with running armv7 compiled software. This blurs the lines between applications designed for mobile operating systems and system servers, and is proving to be advantageous for running high performance software at scale.

The many names of arm64

Arm64 and AArch64 are similar names for the same architecture. Docker architecture names were not standardized until after variations of all architectures had emerged. These get normalized into the specific known architectures Docker respects. AArch64, linux/arm64 and armv8 are all acceptable names and designate the container as built for arm64 architecture. More information on the architectures supported by Docker can be found here.

Building the StackHawk CLI

The StackHawk CLI was developed in Kotlin with Clikt and uses a custom fork of the ZAP core project. HawkScan uses Gradle as a build tool and separates its build process into multiple modules. These modules package themselves into a JAR that is run from a shell script. That executes the compiled JAR with the Java virtual machine installed on the host machine. This is where the Java axiom “write once, run anywhere” comes true; running HawkScan on arm64 worked on day one with our CLI because it is a Java bytecode executable, and the Java 17 executable (and a Microsoft backported version of Java 11) support running on the arm64 architecture.

While our CLI worked seamlessly on the arm64 architecture, more effort was required to get our HawkScan Docker image and platform services working on different architectures. Much of our work intimately involved Docker as a dependency and ensuring that Docker images could be built to be compatible with the arm64 architecture.

Building multi-architecture software with Docker

For those that may not be familiar, Docker is a wonderful collection of software tools, applications and cloud platform services to enable the development of software in containers. Containers run from defined software images, which are housed in container registries.

On OSX and Windows, Docker Desktop is a GUI application, with additional capabilities beyond what the Docker API or CLI typically provide. These utilities help provide a rich experience when developing on these platforms, but creates a disconnect when attempting to automate the building of software in Linux or CI environments.

Docker buildx is a plugin that extends the Docker command to use the BuildKit toolkit and allows for building multi-platform images with Docker Desktop. This is done using the --platform flag to specify the architecture that an image should be built for. Docker Desktop provides build roles for compiling into multiple architectures, but the Linux Docker engine does not have these same capabilities by default.

In order to build for multiple architectures in a Linux environment in CI, you must first start the cross-platform emulator with specific Docker images. binfmt_misc with QEMU emulator support allows for building images for multiple architectures. Docker Desktop includes this emulation support by default, but building outside of the desktop version of Docker will require using the tonistiigi/binfmt image. Additionally, when communicating with the Docker API, the environment variable DOCKER_BUILDKIT=1 must be specified as a property in the API request. This would normally be set automatically by Docker Desktop. More information on building images with BuildKit can be found here.

Registries vs. repositories and images vs. manifests

A registry is a directory of listed container repositories and serves as the location of stored images. A registry may be either local to an individual user’s computer or public in a location such as DockerHub. Google Registry, Amazon ECR and Dockerhub are registries. A repository is a specific location in a registry and exists as a collection of images with associated tags to identify different builds or container contents.

A Docker image is the container built for a specific architecture. Registries can also host manifests, which are associations of common images and the specific architectures they are built for. They allow anyone to pull the manifest as if it were an image and to receive the correct image based on their client architecture.

Using Gradle tasks to build multi-architecture images in CICD

In order to automate the build of our HawkScan Docker image, we used Gradle Tasks to trigger the creation of multi-architecture Docker images in our CICD pipeline. Once the task is triggered, images are built for amd64 and arm64architectures, the images are tagged locally and pushed to Amazon ECR, and then the manifest is generated. The Java API client for Docker was extremely helpful in building out these tasks. We extended this functionality to our platform services, which we can now develop on arm64 machines. This enables us to easily add new architectures to run our software on in the future, and gives our developers the tools to build StackHawk on Apple’s M1 silicon.

Conclusion

Significant research went into learning how to build arm64-compatible images of HawkScan and our platform services. Learning the nuances of how Docker handles multi-architecture builds in different contexts proved instrumental in developing images with arm64 compatibility. Undergoing this process has yielded great benefits as we are ready to build our products and services on existing architectures and on new architectures to come. We hope that sharing these findings will enable you to more smoothly move in the direction of building software compatible with multiple platforms.

Kotlin & Protobuf Tips & Tricks

Topher Lamey

At StackHawk, we've been really happy using Kotlin with Protobuf for the last few years. We have been using the generated Java classes in our Kotlin code, which has worked out well. Recently Kotlin became a first-class language for the protoc compiler, and we are looking to switch to the Kotlin generated classes.

As part of this move, here are some tips and tricks we've learned:

Non-GRPC Protobuf Gradle Plugin Generating Kotlin Classes

The Protobuf Gradle Plugin now comes with built-in protoc compiler support for Kotlin. Unlike Java, the plugin does not enable Kotlin generation by default.

Here's an example Protobuf Gradle Plugin config to generate non-GRPC Kotlin:

Kotlin extension functions for Protos

Adding extension functions to proto messages has proven very useful. Our protos are built and shared with other projects as a jar library. That way, we write extension functions in one place, and they're available to all projects.

Building a field with a function

One case we've had a few times is when we have several pieces of data used to create a single field on a proto. In the following example, the Alert message has a url that gets created with a specific format by two pieces of data, the host and port.

Rather than duplicate the code to add the prefix and colon in the middle of the url string, we can create an extension function to make sure the url variable is created consistently.

fun AlertKt.Dsl.url(host: String, path: String): AlertKt.Dsl { url = "https://$host:$path" return this }

And then use it like so:

fun handleAlert(host: String, url: String) { val alert = alert { url(host, port) } doSomethingInteresting(alert) }

Building a field with a custom builder class

Given the Alert proto definition above, we could also use a custom builder class to build the url field. This is useful when the proto definition can't change.

Here we define a function receiver and associated builder class:

With those, when we go to make an Alert, we can do:

Functions for JSON Handling

We have some projects where we need to convert generated Protobuf objects to and from JSON.

An extension function to generate a JSON string of a given protobuf object works nicely.

fun Scan.toJson(): String = Gson().toJson(this)

For reading in, there are a few options. Here's an example of a simple function that takes the json string and returns a fully realized Scan.

fun fromJson(json: String): Scan = Gson(json, Scan::class.java)

Using the two functions is easy:

val json = scan.toJson() val scanFromJson = fromJson(json)

Wrapping Proto subcollections

We have had a few instances where we've needed to independently export a proto message's collection as JSON. Here's an example to help illustrate:

In this case, we need to generate a JSON array of the scan's alerts. We don't want to create a new proto message that just has a list of alerts. Instead, we can create a custom data class that just wraps the proto objects:

data class AlertsWrapper(val alerts: List<Alert>)

Then we can just add extension functions that know how to read and write the JSON strings:

Then using them looks like this:

val alertsJson = scan.alertsToJson() val newScan = scan { alerts(alertsJson) }

Example Code

All this code, including a working build.gradle.kts that uses the Protobuf Gradle plugin for non-GRPC use can be found at https://github.com/kaakaww/kotlin-extension-functions-for-protos

Rust Broken Object Level Authorization Guide: Examples and Prevention

StackHawk

Broken object level authorization (BOLA) is a serious API problem that can result in attackers deleting, altering, or misusing data. It happens when an API allows a user to access and alter data they shouldn't be able to.

Unlike other security issues, BOLA doesn't necessarily require an attacker to hack their way into a system. If they're aware of the problem, they can create a user and access data without any extra work.

This article will discuss broken object level authorization (BOLA) problems in Rust applications. We'll look at an API example that takes advantage of Rusts' Tide and Diesel crates to avoid this serious security issue, then we'll talk about how to apply these concepts to your code.

Broken Object Level Authorization

When an application doesn't check a user's entitlements before allowing access to a resource, it suffers from broken object level authorization. So, users can retrieve, modify, create and even delete resources because the application doesn't verify user access at the individual item level.

BOLA is a design deficiency. It's easy to enable an application with authentication because so many third-party services and libraries do the heavy lifting for you. The responsibility for ensuring a user has access to the resource they want and the rights to perform the action they need falls to the application code.

Attackers take advantage of BOLA problems quickly. They are very easy to exploit since they only need an unprivileged user and an API tool like cURL or Wget.

A Broken Object Level Authorization Example

RESTful API Implementation

Let's take a look at a simple API for managing blog posts.

The API represents an Article with a JSON object that looks like this:

The client doesn't supply the slug for a new article. When the server creates the article, it returns the slug and acts as the article identifier.

The application offers typical CRUD endpoints, although the endpoints include the slug for operations on an article that exists:

GET /articles/ with no argument retrieves a list of all articles.
POST /articles/ with a JSON record to add a new article.
PUT /articles/{slug} with a JSON record updates an existing article.
GET /articles/{slug} to retrieve an article by slug.
DELETE /articles/{slug} deletes an article by slug.

BOLA API Issue

This is part of an API for a blog site. Users post articles. As time passes, they may decide to update or even delete them. But since posts are associated with users, it's important that only the user that created an article can alter or remove them.

So at a minimum, the website should provide object-level authorization like this:

Users can only read posts without logging in.
Authenticated users may add posts.
Only the user that created a post can update it.
Only the user that created the post can delete it.

A more sophisticated API would add elevated object level authorization for an administrator user, but that's beyond the scope of this tutorial.

Regardless of the details, merely checking that a user has a valid session isn't adequate. The application has to verify that only users can modify their data.

Rust (un)Broken Object Level Authorization

Sample Rust RESTful API

Enforcing proper object level authorization is up to the application, and developers design the best implementations with data ownership and access in mind. We're going to use code from the realworld-tide sample code on GitHub. It uses the Tide crate for serving the web API and Diesel for the database. It's designed from the ground up with proper object level authorization. In other words, it doesn't suffer from BOLA. Let's see how.

Let's start with the routes for managing articles. I've snipped out the rest of the API, so the code is easier to read:

Each route calls a function in the articles crate with the requested information as the sole argument.

First, here's the function for creating a new article:

First, on line #4, this code extracts the article body from the Tide request context.

Then line #8 gets the authenticated user id via the application state, which it also retrieves from the request context. If the requestor isn't authenticated, they receive a 401 error.

Finally, the code retrieves the repository and then retrieves an author object and calls publish. Why not call the repository directly?

A User-Centric Design

Here's the publish method. It's a member of a User class. It's a wrapper for publish_article in the repository. Publish calls the repository with a reference to itself:

This method exists for one reason: to ensure that the article has the correct user associated with it. This association makes sense for a blog site. Articles have authors.

But instead of making the author a text field with a name in it, this design takes it a step further by centering operations on articles on the users.

Update an Article with Proper Authorization

Next, let's trace through what happens when a user tries to update an article.

We start here:

The first few lines are identical to insert_article: get the article body, get the user, and the repository.

Then on line #12, we retrieve the original article before passing it to the User class on line #14.

So, let's take a look at what happens there:

Lines #7 - #12 are where the code enforces object level authorization. Before modifying the object, the code ensures that the authenticated user owns the article.

Before we move on, let's verify that the code enforces proper authorizations for deleting articles:

There's the same check! This code enforces proper object level authorization for blog posts.

Fixing Broken Object Level Authorization

So that's what code that's designed to avoid BOLA looks like. How do you fix existing code?

We can derive basic rules from the code above.

The application must store all objects with an owner. The owner may be a user, a group, or a role.
Users must authenticate before they can alter an object.
Before they alter an object, the application must check that authenticated users own the object or are members of a group or role that has "write" access to the object.

How difficult it is to retrofit this into legacy code will vary.

Do your objects already have a notion of ownership? If not, that's where you need to start.

But, if your objects already have owners, is it easy to access this info from the modify and delete functions? If it is, your work is nearly done! Otherwise, figure out how to expose this to the rest of the code.

Avoiding Rust BOLA

In this post, we covered BOLA in Rust code and how to avoid it. We discussed what BOLA is and how it can lead to serious data exposures. Then we looked at a well-designed Rust application designed to avoid the problem. Finally, we discussed how you can apply these concepts to legacy code.

This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!).

Kotlin Broken Object Level Authorization Guide: Examples and Prevention

StackHawk

Broken object-level authorization (BOLA) is a vulnerability that grants users access to data without them having the necessary privilege.

Broken object-level tops OWASP's API Security Top 10 2023. As a result, it's important to test your application for this type of vulnerability.

In this post, you'll learn about what broken object-level authorization is. We'll also look at some examples of this vulnerability and how to prevent each one.

What Is Broken Object-level Authorization?

What is broken object-level authorization in Kotlin and how do you prevent it? In order to answer both questions, we'll walk through an example of a todo app API. This example API has an endpoint that returns a list of all tasks created by a specific user. Also, each task has an owner ID (user-id) that helps the system know who that task is for.

So, let's say the URL for our endpoint for fetching todo tasks looks like this:

https://example.com/api/todos/{user-id}

Where user-id is the key for fetching all tasks belonging to a specific user.

Now, if a user is able to guess a valid user-id and the system returns the tasks for the original owner of those tasks, we can say there's a potential broken object-level authorization vulnerability.

To further explain what BOLA means, let's first take a look at what object-level authorization is.

According to OWASP, "object level authorization is an access control mechanism that is usually implemented at the code level to validate that one user can only access objects that they should have access to."

From the above definition, we see that the major cause of broken object-level authorization is poor code-level validation.

In BOLA, the attacker takes advantage of an application's features and endpoints that do not perform proper verification of a user's authority before executing a task and returning data. For example, an app that's vulnerable to broken object-level authorization may allow a user to read private data like messages for another user by manipulating request parameters.

Examples of Broken Object-Level Authorization in Kotlin

In this section, we'll look at three examples of broken object-level authorization vulnerabilities in Kotlin. In addition, we'll also walk through how to prevent each vulnerability.

Remember our todo example app API from earlier? We'll be referring to it in these examples. The Kotlin framework Ktor powers the API. In addition, the API stores user data in an SQL database, and we can query the database for specific data using user inputs.

1. Read All Tasks for Specific User

The normal flow of the example app requires that a user can only view a list of tasks they own. That is, the tasks a user creates.

Our example API has an endpoint that returns all tasks for a specific user. As a result, there's code that reads the data from the tasks table on the SQL database. This code depends on a user-id parameter from the API URL. Then, it uses the value for user-id in a query as follows:

todoResult = stmt.executeQuery("SELECT task_title FROM tasks WHERE id=$userId;")

In a vulnerable app, an attacker can modify the value for user-id to a valid ID for another user in our database so that the above code will return all tasks for that user. This is an example of broken object-level authorization because there's unauthorized access to private data.

Prevention

You can prevent this flaw by validating that the user sending the request to the API is authorized to see the task.

We can do this by authenticating the user and sending session identifiers like access tokens as part of the request. However, enforcing only authentication to an API endpoint is usually not enough to prevent access to sensitive data without privilege. In fact, leaving restrictions at authentication only can increase the risk of broken object-level authorization. For example, only checking for authentication may mean that an attacker can authenticate as one user and access data for another user. The following code demonstrates the flow for validating a user before returning data:

if(currentUser.user_id == request.user_id) { return tasks } else { return errorMessage }

2. Read Single Todo Item (Task)

Another feature of the todo app API is an endpoint that returns full details about a specific task. Again, this endpoint depends on an identifier that's part of the URL. The normal flow is that users can only view full details of a task they own.

The following is the URL for the endpoint in this example:

https://example.com/api/detail/{task-id}

Here, task-id is the unique key for querying the database.

An attacker can send random values for task-id until the API returns data when one of the values matches a valid task ID. After that, the attacker will gain access to the full details of the task even though they are not the owner.

Prevention

This type of attack requires the attacker to send multiple requests to the endpoint until the application returns valid data. Hence, in addition to validating whether a user is authorized to see a task, we can reduce some of the risks of this type of attack by rate-limiting our API endpoints.

3. Admin-Only Feature

In this third example, we'll consider an endpoint for admins only that returns a list of all users on the todo app service. This list contains sensitive data like the names and emails of all users. That means if just any user gains knowledge of this endpoint and can access it, then data could be exposed.

For example, the URL for this endpoint is as follows:

https://example.com/api/admin/users/{admin-uid}

The attacker may manipulate the value of admin-uid till they get a valid one. If we don't have enough validation in our code, this API will return the list of users. The attacker can then proceed to use this data for malicious things like phishing and sending scam emails.

Prevention

A good fix for this vulnerability is making sure that the request is authenticated. It's also important to verify that the authenticated user ID is the same as the value for admin-uid.

In addition, if your application has extra fields in the database that defines user privilege, also verify that the current user has admin privilege. In addition to the above method, API rate-limiting can reduce risk here too. This helps by reducing the number of requests the attacker can send to the endpoint before guessing a valid value for admin-uid.

You can also prevent broken object-level authorization include using values that are hard to predict for user IDs and other identifiers. However, you should combine this method with validating a user.

Summing Up

Broken object-level authorization is a type of flaw, usually in the code of an application that can lead to exposure of private user data. A Kotlin application, like an API built with Ktor and SQL, may be vulnerable to broken object-level authorization attacks. Attackers may perform such attacks by manipulating URL and request parameters.

From our examples, the most straightforward method for preventing broken object-level authorization in Kotlin is by validating who a user is and determining whether they can or can't view the data they are requesting. You can do this using a regular if statement.

One final recommendation: In order to reduce the risk of BOLA, you should test your API rigorously for unauthorized access to endpoints and data.

This post was written by Pius Aboyi. Pius is a mobile and web developer with over 4 years of experience building for the Android platform. He writes code in Java, Kotlin, and PHP. He loves writing about tech and creating how-to tutorials for developers.

Guide to Security in Kotlin

StackHawk

Security is a very important aspect of software development. However, securing applications can mean different things. For example, security in Kotlin may refer to being able to run your Kotlin application safely in JVM. Or security may be at the Kotlin language API level.

Another highly important level of security to consider as a developer is application security. Application security here refers to security vulnerabilities that exist when hackers take advantage of the code and features on your application to steal data or crash your entire service.

The Kotlin team has a bigger part in the responsibility for fixing security vulnerabilities relating to JVM and the language APIs. And they do this mostly by releasing updates and patches to Kotlin. In addition to that, they may also publish instructions for blocking vulnerabilities.

Application security, on the other hand, requires more effort from you, the developer. Examples of application security vulnerabilities include SQL injection, command injection, and XSS. So, fixing application security issues includes testing and patching a vulnerability like SQL injection,cross-site scripting, command injection, cross-site request forgery, and HTTP strict transport security header.

In this post, we'll learn about security in Kotlin and see different ways to build a more secure Kotlin app. So, let's get started.

Kotlin Security: Strengths and Weaknesses

Is Kotlin a secure language? What are its strengths and weaknesses? We'll answer both questions in this section.

Strengths

Like many modern programming languages, Kotlin strives to be a secure, fast, and user-friendly tool in the hands of developers. The following are some of Kotlin's strengths.

1. Fewer crashes thanks to null safety: At the language API level, Kotlin offersnull safety to reduce crashes in your application due to unexpected data or user input. When used properly, Kotlin's null safety can prevent NullPointerException.

2. Data encryption: Kotlin has good libraries that make it easier for developers to encrypt data. One example of Kotlin data encryption libraries isJetpack Security.

3. Frequent updates: Security is a continuous process. The team at Kotlin is always identifying new vulnerabilities, and they release patches to address any issues that may have been found.

Weaknesses

Some of Kotlin's security weaknesses include:

1. Reverse engineering—It's possible for someone with enough technical knowledge to reverse engineer your Kotlin app, hence, giving them more understanding of the internal working of your app. Also, if you bundle sensitive data like API credentials in your app, they may be exposed too.

2. Internet-driven APIs—Most programs need to connect to the internet for one reason or another. Kotlin has a few built-in tools for powering the internet-driven functionality of apps. Two examples are HttpsURLConnection and WebView. Making HTTP requests via non-SSL protocol can expose sensitive data in transit. Similarly, wrong use of the WebView API such as allowing the execution of any JavaScript code and allowing users to visit any URL via your app can increase security risk.

Features That Increase Kotlin Security

Underneath, Kotlin is just like other programming languages and contains several security features. However, in this section, we'll take a look at two Kotlin-specific features that make Kotlin more secure.

1. Immutability: One way Kotlin improves on Java is by offering keywords for declaring a variable as mutable or immutable. These keywords are val and var. Variables declared with val are immutable, meaning that you cannot reassign a new value to it later in your program.

2. Null safety: Earlier, we mentioned null safety as one of the strengths of Kotlin. This feature helps developers write more secure applications. For example, with null safety, developers are more likely to catch and provide a safe path for code execution in the event of unexpected null values. In other words, this can reduce the occurrence of a NullPointerException.

Kotlin Libraries and Framework

In this section, we'll take a look at some popular Kotlin libraries and frameworks and how they handle security.

1. Ktor

Ktor is a framework for building web applications and microservices using Kotlin. One example of how you can use Ktor is for developing a RESTful API that a mobile or web app can interact with via HTTP requests. In addition, you can render HTML responses directly using Ktor. In that case, you can build a full-stack web application using Ktor.

Ktor is flexible and can integrate with other tools to build complex applications. For example, you can use Ktor with an SQL database to persist data. However, poor implementation of features may leave your Ktor application open to security issues like SQL injection.

2. Spring

Spring is a popular Java framework for building microservices and general web applications. Starting from the fifth version of the Spring project generator, you can generate a new Spring project using Kotlin.

A Spring application may also be vulnerable to SQL injection and XSS attacks, among others.

3. Javalin

Javalin is a lightweight Java and Kotlin framework that offers WebSocket, async requests, and HTTP2 support. One of the strengths of Javalin includes the fact that it's ideal for building RESTful APIs. For example, it has great support for OpenAPI and can be used with tools like Swagger. In addition, Javalin applications run on Jetty, a very popular JVM web server.

Again, Javalin applications that aren't properly optimized may be vulnerable to security issues.

Kotlin Security Libraries

1. Hibernate Validator

Hibernate Validator is a library for Java and Kotlin for validating data like user input. Applications that parse user input without proper validation are more likely to be vulnerable. As a result, attackers take advantage of them to perform attacks like XSS, SQL injection, and other command injection attacks.

Using this validation library, we can reduce the risk of attack to a great extent. The following is an example of how Hibernate Validator works:

Data class

data class UserDto( @field:Max(value=100) @Email() val email: String, @field:Min(value=8) val password: String )

Application class

From the example code above, we use the @Email annotation to validate that the value for email is an actual email address. We also verify that the length of the password is greater than eight characters using the @Min annotation.

2. Ktorm

Ktorm is an object-relational mapping (ORM) framework for Kotlin. In simpler terms, it's a tool that makes working with relational databases like SQL easier.

The following example shows SQL queries using Ktorm API:

Data class

object Users : Table<Nothing>("users_tbl") { val id = int("id").primaryKey() val email = varchar("email") val password = varchar("password") }

Application class

In the example above, we're printing values from users_tbl. Thanks to Ktorm's Kotlin DSL, we didn't have to write any raw SQL queries.

Using an ORM can reduce the risk of SQL injection. However, it's worth mentioning that if you write a lot of raw SQL queries while using an ORM, your application may still be vulnerable. In the next section, we'll look at other practices for increasing the general security of Kotlin.

Kotlin Security Best Practices

A combination of the following practices can reduce security risk in Kotlin.

1. Validateuser input before parsing or outputting them. Failure to do so can expose your application to SQL injections and XSS attacks.

2. Avoid storing API configuration keys in code. Earlier, we mentioned that one of the risks posed by reverse engineering is the exposure of sensitive information like API keys. In order to reduce this type of risk, you should avoid storing API keys as strings in your application. Instead, use environment variables where possible, or use other methods to encrypt keys.

3. Keep tools up to date. Always keep the version of Kotlin your application is using up to date. In addition, if you're using any other third-party libraries and dependencies, you should also keep them up to date.

4. Encrypt data before sending it over a network. If your application sends sensitive data like messages and passwords over the internet, use good encryption methods to encrypt such data before sending them. Doing so can reduce the risk of data being intersected and read in transit.

Common Security Attacks in Kotlin

Some of the most common application security risks in Koltin include the following:

1. SQL Injection

SQL injection is a type of attack where the attacker manipulates SQL queries on a vulnerable website or application.

In order to perform this type of attack, the attacker usually targets features that accept user inputs. For example, the attacker may manipulate the value for an ID in the URL of a web application.

A good method for preventing SQL injection is by validating user input before using them in SQL queries. Another option for preventing SQL injection is the use of PreparedStatement.

2. Cross-site Scripting (XSS)

XSS is a type of security vulnerability that allows users to inject malicious JavaScript code into a website.

An attacker can perform an XSS attack using various methods, including pages that display user inputs. For example, the attacker may submit malicious code using the reply feature on a website that allows users to reply to posts. The malicious code is then executed any time a regular user loads the page containing the reply.

One effective method for preventing XSS attacks is by validating and sanitizing user inputs.

3. Command Injection

Command injection is an injection attack where the attacker injects malicious code into the server. The server or back end then runs this code like the normal application code, thus, granting the attacker access to data and other resources.

This type of attack can be done via user input. The attacker may inject code via a URL query parameter.

A good practice for preventing command injection is avoiding the use of functions that execute commands in our code. In addition to that, sanitization of user input can reduce risk.

4. Cross-Site Request Forgery (CSRF)

CSRF is a type of attack that takes advantage of the trust a website has for authenticated users. In this attack, unauthorized commands are executed on behalf of an authenticated user.

One way attackers carry out this attack is by tricking unsuspecting authenticated users to click manipulated URLs for the target application.

To beat CSRF, applications should verify whether a request is forged or not before performing commands.

5. HTTP Strict Transport Security Header

HTTP strict transport security header makes it possible for browsers to restrict access to a site to only HTTPS requests. Sending data over the nonsecure HTTP protocol can expose data in transit.

To prevent strict transport security header-related vulnerabilities, enable HTTPS on web applications.

Conclusion

To conclude, here are a few points that sum up our discussion on security in Kotlin:

Kotlin, just like most popular programming languages, gets consistent updates that patch security vulnerabilities.
However, application security depends on how a developer uses features and tools on their app. You should always test your applications for common security vulnerabilities.
Finally, keeping all tools—including third-party dependencies that you use in your application—up to date can also improve security.

Guide to Security in Node.js

StackHawk

In this post, you're going to learn about security in Node.js and best practices to secure your Node.js apps. Security, in this case, means safeguarding data. To build great software and systems, you have to think about security from the first stage of your development roadmap. This means that security should be at the core of your software development process.

This guide will take you through key security concepts to consider when building software using Node.js. Let's start by seeing how Node.js already supports security practices.

Security and Node.js: A Primer

Most importantly, the strength of the Node.js core lies in the community around it. The Node.js community prioritizes security as a key factor in the development of Node.js. This has led to the creation of the Node.js Security Working Group (SWG), whose mission is to improve the security of applications built using Node.js. It does so by bringing vulnerability data from the community to the Node Security Platform, while also maintaining the vulnerability data on disclosed security vulnerabilities. The SWG also ensures vulnerabilities in Node packages are properly documented and, consequently, makes known security issues openly reported.

However, you should note that SWG is not responsible for managing or responding to security reports against Node.js itself. The Node.js TSC owns that responsibility.

Relevant Libraries or Frameworks in Node.js

Node.js has several modules that improve the efficiency of software applications. Accordingly, properly integrating these modules will improve the security of your Node.js applications. In addition, these modules are free to add, and they improve the overall efficiency of Node.js apps while tightening up loose ends. I'm going to go over a few of these libraries and frameworks.

1. Express.js

The first on the list is Express, which is a Node.js framework that you can use when you need to easily handle verb actions like GET, POST, and DELETE requests in Node.js. It handles each of these requests with different paths known as routes. Express.js uses the Node.js middleware idea to deliver middleware modules that solve specific and key problems in Node.js like security.

Next on the list is Helmet.

2. Helmet.js

Helmet is an Express middleware, and it helps in setting various HTTP response headers for securing GET and POST requests in Node.js apps. It's used as an HTTP Headers Security module. It delivers middleware functions that set HTTP headers.

These HTTP headers include the following:

helmet.contentSecurityPolicy() sets the Content-Security-Policy header, which helps mitigate cross-site scripting attacks (XSS).
helmet.xssFilter() disables browsers’ buggy cross-site scripting filter by setting the X-XSS-Protection header to 0.

You can go through this list to see all the HTTP headers you can set up in your Node.js application using Helmet.

Next, we'll go through the Node.js module for securing passwords, Bcrypt.

3. Bcrypt

Bcrypt is a password security module offered by Node.js. The Bcrypt library protects users from attacks like brute-forcing. This is made possible through a hashing method called salting. To clarify, salting is a technique that involves the act of adding random strings to passwords before the actual hashing takes place.

In order to do that, "the Bcrypt library uses a .genSalt() method to generate a salt and hash," according to the Bcrypt documentation.

With separate functions for both salt and hash, you can generate a password hash, and then a salt, like below.

And with separate function calls, you can auto-generate both a salt and a hash, like below.

Passwords can be checked for correctness by using the block of code below. The function returns true when the hashed password matches the plain password.

4. Validator.js

Next on the list is Validator, which is an input validation module. It enforces the need for user inputs to be what they're required to be. In the same vein, it ensures input correctness. This list includes all the validators you can configure with the Validator package.

5. ESLint Plugin

Another way to improve your Node.js app's security is to integrate ESLint, which is a linting security plugin that helps to identify vulnerable Node.js code during development. Vulnerable code implementations include unsafe regular expressions, an ‘await’ keyword inside for loops, and so on.

You can get more details on how to use this plugin to write less vulnerable code here.

Security Best Practices

Regardless of what applications you're building with Node.js, you should carry out key security procedures at the first stage of development.

So, to keep your Node.js application secure and free of vulnerabilities, it's important to implement essential security best practices while building out your Node.js app. We'll go through a couple of those in this section.

Always Audit Node Modules

Firstly, it's imperative to always audit each node module you use in your project for vulnerability checks. Auditing helps to confirm which package is available for an upgrade. When you audit packages, you're also confirming the security of the package.

Consequently, in order to audit packages/modules and check for vulnerable dependencies, you can use tools like Snyk, Node Security Project (NSP), or run npm-audit to track down and patch vulnerabilities.

Always Use Rate Limiting

Secondly, attacks like brute forcing are a common security threat to Node.js apps, and login routes are the most targeted for this form of attack. Rate limiting helps to limit the impact of brute force attacks. The Node.js ratelimiter package helps in the integration of rate limiting into your Node.js apps. With the ratelimiter module, you can limit middleware implementation against the ID of a user.

The Express Brute package also does rate limiting to mitigate brute forcing and denial of service (DoS) attacks.

Use TLS/SSL for Data Transmission

Thirdly, data confidentiality is important when transmitting data from one layer to the other, to prevent sniffing from potential attackers. One common way to secure the transport of data through encryption is to use transport layer security (TLS) and secure sockets layer (SSL). To clarify, SSL encrypts the client-server connection end to end, and TLS secures password data and sensitive information like credit card details.

Escape Outputs

Furthermore, in order to avoid injection attacks like cross-site scripting (XSS), output escaping plays a key role. XSS will be explained later in this post. To escape outputs in your code, you can make use of the Node ES API library or the Escape HTML library to escape all JavaScript and HTML code that users get access to.

Log and Monitor Your Apps

Finally, loads on servers can cause DoS, which may lead to app downtime. It's therefore important to monitor incoming and outgoing traffic into the servers, and you can always be alerted when servers are under extreme load. And if your servers are crashing not because of extreme loads, but due to security attacks, it's imperative to use logs properly to understand how and when the security attack happened. The Bunyan Node.js module helps in the efficient logging of your Node.js services. The TooBusy Node.js module is an essential tool for monitoring Node.js apps.

The OWASP Node.js Security Cheat Sheet includes a comprehensive list of security best practices. Understanding security attacks and key ways to mitigate these attacks is a key security embrace—and this is what the next section entails.

Most Common Node.js Security Attacks

There are several Node.js security attacks, but we'll review the common ones in detail in this section.

SQL Injection

SQL injection involves the insertion of an SQL query through input data from the user to the application. These attacks make use of areas in applications that ask for user inputs. The attacker carrying out the SQL injection attack will be able to gain access to the database of the application after a successful attack. You can read more on SQL injection on StackHawk.

To prevent an injection attack, input validation is key, and the Validator package mentioned above helps with proper input validation. The Validator module has allowlist and blocklist validation methods that are about explicitly declaring what you want to be authorized in your input validation process and blocking out everything else.

Cross-Site Scripting (XSS)

XSS involves the injection of client-side scripts into websites. With XSS, attackers are able to manipulate web applications with the aim of sending malicious code to the users of the web app. XSS attacks have the objective of either stealing users' data or taking control of the web application.

To prevent an XSS attack, you'll need to use secure HTTP headers according to the requirements of your project. Helmet, mentioned above, delivers middleware functions that set secure HTTP headers.

Command Injection

Command injection involves the injection of input that alters valid and legal commands in vulnerable applications in order to execute illegal commands against the operating system. This attack is mostly against the system shell. The input injection can come from any source that the user can modify, such as forms. This attack targets the system shell.

Again, to prevent an injection attack, input validation is key.

Cross-Site Resource Forgery (CSRF)

CSRF is a form of session hijacking where a user is forced to run malicious actions on an application that they're currently authenticated to. In a CSRF attack, attackers hijack the sessions of real users, thereby bypassing security rules for non-users.

To prevent CSRF attacks, you need to implement tokens that will be generated on the server side. The csurf Node.js package helps in the generation of valid CSRF tokens. OWASP has also provided best practices for generating tokens.

Path Traversal

Path traversal involves the act of accessing directories in a file server illegally due to weak security validation. In this kind of attack, an attacker is able to access server files by the injection of malicious user inputs into the web application. This attack feeds upon vulnerable implementations of access control settings.

To prevent an attack of this form, allowlisting plays a key role. Input validation plays a vital role, too.

Conclusion

In this guide, you learned about security essentials in Node.js, the packages and libraries available to mitigate vulnerability attacks, and best practices to tighten up security in your Node.js app. Certainly, security should be a priority during development and enmeshed in every facet of your next Node.js app.

Guide to Security in .NET

StackHawk

The .NET Framework is Microsoft's primary enterprise development platform. It comprises a set of APIs for developing applications for desktops, servers, and the web. Its roots extend back to 2002 as a proprietary framework for Windows. But since then, it's transformed into a free and open-source framework for Windows, Linux, and macOS.

The .Net framework has been around for a very long time and is the enterprise framework for one of the most common operating systems in use. So, it has its share of exploits. But Microsoft and the open source community provide excellent support for the framework. As a result, you can write secure and safe applications by following Microsoft's guidelines and employing the same best practices as any programming framework.

Let's look at .Net's security features, some best practices for .Net developers, and how the framework fares against some of the most common security threats.

.Net Security Features

Principal and Identity Objects

When managed code runs under .Net on Windows, it can access Windows' identity and principal subsystem. So, .Net apps running on Windows have access to Windows security and role-based access control. But, .Net Core doesn't have the same level of access to user and authentication resources on Linux and macOS. Therefore, cross-platform applications need some extra help with authentication.

What .Net Core does have is the IAuthentication service. Applications can it use to access third-party authentication services such as Twitter, Google, and in-house OAuth services. In all cases, authenticating a user with the .Net framework creates a Principal object that's useful for operations like role-based security.

Role-Based Access Control

If you use .Net's authentication services, you get access to role-based access control (RBAC), too. The .Net framework has built-in support for RBAC. Used properly, RBAC will protect applications from many common attacks. Having support doesn't automatically make .Net secure, but having the behavior built-in means you don't have to write it yourself, and the functionality has been tried and tested.

Managed Execution

.Net compilers compile code to Microsoft intermediate language (MSIL) for distribution. Then, a just-in-time compiler compiles it to native code at execution time.

Part of compiling MSIL to native code is a verification process that examines the code and its associated metadata. Microsoft confusingly refers to this check as "type safety," even though it's not related to the type safety enforced in programming languages.

MSIL code may only access authorized memory locations. This ensures proper isolation between modules and verifies that the runtime can enforce security restrictions.

System administrators can override this verification step on a specific piece of code or a systemwide basis. But, this is almost never a good idea.

Security Best Practices

Don't Override Code Verification

Our first best practice recommendation is not to override the "type-safety" verification check outlined above. While this check is not perfect, and it's even possible in rare cases for valid code to fail the check, running untrusted code is never a good idea. Supply-chain attacks on systems like Nuget make running untested and unverified code too dangerous.

If you must run untrusted code, take additional security measures such as running the application in containers or virtual environments where the unsafe code is isolated.

Verify User Input

If you don't carefully verify and sanitize user input, it can cause your application to misbehave. While .Net has mechanisms for verifying code that calls your application or library, you're on your own when it comes to user-specified information.

Here's a brief list of checks you should make against user data:

Always verify and sanitize URIs. Be careful of:
- Relative paths
- Very long paths
- Any and all wildcards
- Special paths, like file://, socket://, etc.
- Token expansion (%token%)
- Hexadecimal and Unicode character escapes
- Nested escapes (%nn becomes %mmnn, where %mm is the escape for '%').
.Net's Eval() can execute any arbitrary code. Avoid it.
Beware of late binding that may point to user-specified data.

All of the common attacks we'll examine below involve malicious input.

Verifying and cleaning user input is one of the most important security precautions you can take.

Keep Your Packages up to Date

.Net has a mature and robust package ecosystem. This makes it easy to keep your dependencies up-to-date with Nuget. Make checking for updates a part of maintenance. Then, rebuild and test your code with the new libraries as part of your regular release process.

Most Common .NET Security Attacks

Finally, let's wrap up by looking at four of the most common .Net Security threats.

SQL Injection

A SQL injection attack is when a malicious actor takes advantage of an application that doesn't properly sanitize its input. It leverages this weakness by coercing it into executing SQL statements. It's a very real threat, and an improperly coded .Net application is vulnerable to it.

You can read about SQL injection and how to protect your .Net application here.

Cross-site Scripting (XSS)

XSS is another type of injection attack. These attacks occur when an attacker tricks a website into running a harmful script by injecting it as—you guessed it—malicious input. XSS attacks usually leverage the <script> tag, hoping the site will accept and run it.

You can learn more about XSS and how to protect your .Net application here.

Cross-Site Request Forgery (CSRF)

Cross-site request forgery is a mouthful, but the name tells you exactly what it is. It happens when a forged request from a rogue website tricks an authenticated user into running harmful code. This attack relies on a user being logged in and having access to privileged information or resources, like credit card numbers or access to a bank account.

When this attack works, it can be devastating. Read more about CSRF and how to protect your .Net code from it here.

XML External Entities (XXE)

An XML External Entities attack leverages vulnerabilities in how an app processes XML. It's another type of injection attack. XML documents contain constructs that make it easy for apps to access external data. But, these mechanisms are dangerous in the wrong hands. So, an attacker can trick an application into downloading malicious code from another site. Or, it can trick a server into supplying sensitive information. Even worse, a properly crafted document can act as a denial-of-service attack by causing a server crash.

We have details on XXE attacks and how to address them in .Net here.

.Net Security

We started with .Net's security features. Then we discussed some development best practices. Finally, we wrapped up the most common .Net security threats and supplied links to articles that will help you address them. As you can see, securing .Net applications doesn't have to be hard.

With the right information and the correct tools, you can keep your code and your users safe.

Are you responsible for delivering fast, safe, and secure .Net solutions? With our Dynamic Application Security Testing (DAST) suite, you can take the next step. Our DAST tool runs security tests against your application while it's running. It'll identify potential security vulnerabilities and help you fix them. So, you'll have real-time, reliable, and detailed reports about the security status of your platform. The DAST suite ensures that you get the best insight and tools to provide reliable decision-making information so that you focus on delivering value,

You can check it out here.

Rails Excessive Data Exposure: Examples and Prevention

StackHawk

For software engineers, it may be easy to assume that no hacker would target our app since it isn't big or well known. This attitude can lead to recklessness and lower measures for securing data on an app. However, it's important to remember that data collected by an organization is very valuable. There can also be legal consequences in terms of lawsuits against the business that ensue from leakage of a user's personally identifiable information (PII).

What Is Excessive Data Exposure?

Excessive data exposure occurs when an API response returns more data than the client needs. As a rule of thumb, if a client application needs three fields, for example, you shouldn't return the whole object. Excessive data exposure is a big API security concern that should be at the top of every engineer's mind when designing APIs.

In this post, you'll learn about excessive data exposure in Ruby on Rails. By the end of the post, you'll have learned about the following topics:

Levels of data sensitivity
Examples of excessive data exposure in Ruby on Rails
Excessive data exposure prevention measures

Levels of Data Sensitivity

Once data has been obtained from users, it's classified according to its sensitivity in terms of the effects it could have on an organization if altered or stolen by a third party. In this section, you'll learn about the four levels into which you should classify your data.

Public: This is data that poses no security threat when presented to the general public. This includes data such as workers' directories, password validation prompts, etc.
Internal: This is internal data that is used within the organization and would be harmful if exposed to people outside the organization. An example is email correspondence that doesn't contain confidential information.
Sensitive: This is data that belongs to users in an organization and is highly confidential. Examples are credit card information, social security numbers, API keys, access tokens, etc.
Restricted: This is data that only a few members of an organization have access to, such as highly classified business information.

Now that you've learned about the different tiers of data sensitivity, in the section below, we'll take a look at a sample API response in order to learn more about excessive data exposure.

Sample API Response

For this example, let's say a gaming application API that shows a user's profile may return a raw user object that looks like the code snippet below to the client application:

At first glance, you may not notice anything wrong with the API response above. But you'll see in the next section how returning this kind of raw data can lead to excessive data exposure in your Rails application.

Examples of Excessive Data Exposure

The API response above leads to excessive data exposure in the following ways.

Returning Unfiltered Data

The API response above returns raw unfiltered data, leaving the client app to filter out sensitive information about the user. The client application only needs the username, bio, and level fields, making the extra fields that are returned useless. In this instance, returning more data than the client application needs is a case of excessive data exposure.

If a hacker were to intercept this API response, they could view all the sensitive data and, worse, make a copy of the data and sell it on the dark web.

Using Auto-Incrementing Primary Keys

A Postgres database, by default, uses auto-incrementing primary keys unless otherwise specified. Since the primary keys are sent with the URL as an ID, anyone sniffing the website traffic could access the ID, which would be a sequentially incrementing integer. It lets the third party know the order of magnitude of a database. For example, if the API to get a user's data is /user/1870, they know that your database has stored data for a couple of thousand users.

Returning Personally Identifiable Information in an API Response

PII is any data that can be used to identify a person and is never shown on a website or mobile app. PII includes the ID number, email, credit card details, social security number, home address, driver's license, etc. of a person. Returning PII in an API response is a big data breach and a case of excessive data exposure. If hackers gain access to PII, this could result in lawsuits from the users when discovered, which could then lead a small company to bankruptcy. API security is extremely important for both the company and its users.

You've seen instances of excessive data exposure and how API design flows lead to security vulnerabilities. Therefore, in the next section, let's now learn about preventive measures.

Protective Measures

Listed below are some of the ways you can protect your Rails application against excessive data exposure.

Don't Use Auto-Incrementing Primary Keys

Since primary keys are publicly discoverable in the URLs and network logs as ID values, it's better to use universally unique identifiers (UUIDs). UUIDs are random and unique, and nobody can guess the order of magnitude of your database.

Implement Server Authorization Checks

Use the CanCanCan authorization gem. It defines access rules that restrict someone from viewing somebody else's record by changing the ID in the URL. The user cannot change the ID in the URL to view another user's profile data unless authorized.

Use Data Masking

Data masking is used to hide sensitive information in your database, like a user's email, and only display the nonsensitive information in an API response.

Encrypt Your Data

If your app must store personally identifiable information, it should all be encrypted. Encryption protects all sensitive information from prying eyes. With encryption, even if an attacker got a snapshot of your database or API response, they wouldn't be able to make sense of the data.

Don't Return a Raw Unfiltered API Response

When designing APIs, use the principle of least privilege by only returning the data a user needs. Returning raw unfiltered data to a mobile or web application is never a good idea. Examine every API response, and filter out the data the user doesn't need on the server before it's presented to the client.

Don't Store Sensitive PII Data

Use a third party to store sensitive data. For example, for all credit card details, you should store them in a third party like Stripe. In this scenario, under no circumstances will the credit card details show up in any API request since you don't store them in your own database.

You should evaluate whether your APIs are secure from what you've learned in this article. And if they're not, you should consider using some of the preventive measures stated above.

Conclusion

In this post, you learned what excessive data exposure is, the levels of data sensitivity, and examples of how you could contribute to excessive data exposure when designing your Rails APIs. Finally, you learned about the measures you need to put in place to prevent excessive data exposure.

Data is a very important asset to any company that should be protected at all costs. Ensuring your users' data is secure protects your company from losses emanating from lawsuits and protects the company image. In the case of API requests, you shouldn't return all the fields stored in the database by default. Data security helps customers trust your business with their data.

This post was written by Florence Njeri. Florence is a Software Engineer with experience in mobile development in Kotlin and Java, backend in Ruby in Rails and Java, and front end in Vue.js and React. While not coding, you'll either find her reading or hiking during the weekends.

Angular Excessive Data Exposure: Examples and Prevention

StackHawk

As a front-end developer, you've built tons of great features. You've handcrafted amazing UI/UX elements. You've probably also catered to security concerns in a web application. But when it comes to back-end interactions, you might feel limited in what you control, especially with respect to the data that comes back from the server.

Even with the utmost caution, a common yet lethal vulnerability in your application can be introduced. The reason for this could be simply because the server sends back unnecessary or extra sensitive data back to the client. This leads to excessive data exposure in your application. So what can we do about it? How can we prevent it?

In this post, I'll show you what excessive data exposure is, and I'll provide you with some examples. Then I'll walk you through how you can prevent it in your Angular application.

What is Excessive Data Exposure?

Let's say you have an Angular application that interacts with a remote back-end server to get a bunch of data for different pages. Whenever your users loads a page, you request the required data from the back end and display it to the user. So, for example, if your user is visiting an "offers" page, you display them a bunch of cool offers on your website.

Now, if they visit a different page, say an "about" page, you display your website's "about" information fetched from an API. But are your Angular components really aware of what data each API is returning? Or are they only concerned with the data that they require in that instance?

I bet it's the latter. This is because how your back-end APIs are structured is immaterial to your front-end codebase. So when you visited the "offers" page, maybe the API returned the offers data alongside some extra information that you're not using. But wait, no big deal, right? As long as the front end receives the data it wants, everything else can be ignored, correct?

Not exactly. We know that browsers make it really simple to inspect network requests via the developer tools.

The extra sensitive data that your back-end API returns can be of significant use to an attacker.

They can use it to steal some information about your users.

This is called excessive data exposure. It's a situation where critical and sensitive data is unnecessarily exposed by your application. If this was hard to understand, let's dive deeper into it with an example.

Excessive Data Exposure: Example

Let's say your Angular app is a social media application. Your users can create their own profile, share posts, etc. Let's say your users can share someone's profile with other users. So when you click the Share button, you can see that user's profile. Sounds good and safe, right?

But now let's say that the back-end API that fetches a user's data accidentally also fetches that user's access token. You'll probably ignore it, or you may not even notice it since you don't make use of that data on the front end anywhere. However, that piece of information is sensitive, and literally anyone can extract it by inspecting the network request on that page.

Here's the entire flow demonstrated visually:

This is an example of excessive data exposure. An attacker who gains access to a user's access token can easily break into their accounts. Then they can modify their information in your database. They can even gain access to data such as their passwords, bank details, etc.

Methods to Prevent Excessive Data Exposure

We'll talk about two primary methods to prevent excessive data exposure. Each of these methods assumes a different kind of API architecture for your application.

Back End Based Prevention

First, if you're using REST APIs, you need to refactor those APIs in terms of what data they're sending back. Sometimes an API runs a query to grab all the data in a row of a table and dumps it back to the client. With this, it may send data that's of no use to the client and is also considered sensitive from a security standpoint.

For instance, in the previous example, the API was sending back access tokens for a user. The way around this is to have the API filter out this data on the back end, either directly in the database query, if possible, or at the time of processing.

Front End Based Prevention

However, what happens when you're using third-party APIs? Or what do you do in cases where you don't want to modify your back end? Let's assume your front end consumes data from GraphQL-based APIs.

GraphQL gives your front end full control over what data it receives and processes. You can more responsibly update your GraphQL query to only request data that you need. You can also carefully craft your query such that you don't end up requesting sensitive data points that can be avoided.

In case you're not using GraphQL for your backend APIs, you can ensure that your front end does all of the following:

Doesn't leak sensitive data via browser storage (local storage and session storage) or cookies that can be easily spotted.
Doesn't store sensitive data in local variables or in data attributes of DOM elements that can be extracted via client-side JavaScript.
Ensures client and server interaction happens over only HTTPS, which encrypts data by default.

However, these are just some best practices you can adopt to add another layer of security to your front end. It doesn't necessarily protect sensitive data from being exposed, since the attacker can always see such information in the network tab of the browser.

Practical Prevention of Excessive Data Exposure in Angular

We've seen a lot of theory, but let's put it into some practice. For this tutorial, we'll use an open GraphQL API called GraphQLZero. If you wish to explore this API, you can do so in the GraphQL playground here. You can generate the query for getting response back from the API and then update the query to see how the response changes.

For now, let's first go ahead and create a new Angular app.

Create a New Angular App

Inside a directory of your choice, run the following command to create a fresh Angular project:

ng new angular-excessive-data-exposure-app

We won't need routing or any additional configuration, so feel free to skip that when prompted in the CLI. Once you do that, you should have a new Angular project created for you. Now, let's update its app.component.html file with the following code:

<h1>Angular Excessive Data Exposure App</h1>

Now, let's kickstart the Angular local development server by running the following command inside the root directory:

ng serve

If you now visit http:///localhost:4200, you should see the following page:

Awesome! Let's move ahead.

Introducing a Case of Excessive Data Exposure

First, we'll create a case of excessive data exposure by requesting extra data from the API. Head over to the app.component.ts and add the following variables inside it:

The apiUrl simply holds a string to the query endpoint. Then, we have a query string object that we'll use when we make a request to the GraphQL API. Finally, we have a userData variable to store the user data that we get back from the API as response.

Now let's make the request to the endpoint. Inside the ngOnInit lifecycle method, add the following code:

We simply use the fetch API to make a request to the above GraphQL API. We also pass the query string inside the JSON body. Then we process the data and store the relevant result inside the userData variable. Makes sense?

Now, we'll consume this data in our template. Head over to the app.component.html file and update it with the following code:

Now go back to your app and you should see that data displayed on the page:

Great! Looks like you did everything correctly, right? Well, not exactly. We're only using the user's username, email and location fields from the response in the UI. But let's inspect the entire request and response from the browser's network tab:

Notice that we also get back the user's ID. Imagine if this ID is an access or authentication token equivalent. It's a sensitive piece of information that's clearly not of any use here. Looks like we have an excessive data exposure vulnerability!

How to Prevent Excessive Data Exposure

Remember when I said that with GraphQL, a front end has complete control over what data it requests and what information the API sends back in response?

If you look closely at the query, we explicitly ask for the user's ID. If we remove it from the query, the API should not send that data back at all. So let's try to do that. Here's what the updated query string should look like:

We now no longer receive the id field back. Great! We have just prevented excessive data exposure by cautiously modifying the GraphQL query.

Conclusion

If you're not using GraphQL but instead using REST for your back-end APIs, your front end can't do a lot to protect your application from excessive data exposure. So always make sure your REST APIs are structured in such a way that they only send back the data needed. However, as wise front-end developers, you can prompt your back-end team to be more cautious about what data they're sending and play your own part in responsibly preventing excessive data exposure in your application. Until next time!

This post was written by Siddhant Varma. Siddhant is a full stack JavaScript developer with expertise in frontend engineering. He’s worked with scaling multiple startups in India and has experience building products in the Ed-Tech and healthcare industries. Siddhant has a passion for teaching and a knack for writing. He's also taught programming to many graduates, helping them become better future developers.

Spring Excessive Data Exposure: Examples and Prevention

StackHawk

An API is essentially a tool to provide an interface for the client with the software—that's what they do.

Some of the API methods modify application state and some return data to the client. Further, some methods can do both. Once we return data to the client, we need to make sure that we return only what's necessary and don't expose any sensitive information.

This post will cover excessive data exposure in APIs with examples and prevention methods. The examples will be given in the context of the Java Spring framework.

REST API Structure

Usually, REST APIs follow a standard structure for the API calls. The structure usually consists of a domain name, a resource, a sub-resource, and a specific endpoint. For instance, a URL that looks like this— http://domain.com/artitsts/artist/albums/album1/song3—will allow a user to use different HTTP methods (GET, POST, PUT) to retrieve, update, and upload songs from a specific album for a specific artist.

Additional endpoints can be http://domain.com/artitsts/albums/album1, which will return a list of all the songs in an album, and http://domain.com/artitsts, which will return a list of items.

API Structure-Sniffing Vulnerability

The first vulnerability associated with this structure and excessive data exposure can occur if an attacker guesses or receives a list of endpoints.

If an endpoint that exposes sensitive data doesn’t require authentication, as explained here, the attacker can gain access to data he's not authorized to view.

That said, the attacker can use brute force to identify API endpoints. This can be achieved by randomly trying to generate URLs that'll return a response, or by using a list of popular paths to see if the server returns a response for them.

For instance, a popular REST API path is /users/info. Another one is /admin. So, the attacker will create a script that checks those paths combined with a domain name—http://domain.com/users/info, http://domain.com/admin—and see if any of them returns a response.

Another Way of Sniffing API Structure

The REST API standard includes a specification called HATEOS, which basically means that every API response should return a list of links to other API endpoints that can be relevant to this specific endpoint.

If the API developer just blindly returns a list of all the API endpoints in the system, or returns API endpoints that should be password protected but aren't, he exposes data for attackers.

An example of a HATEOS response, taken from the relevant Wikipedia entry, is

API Endpoint Sniffing

Another way for the attacker to gain access to sensitive information doesn't even require any extra effort of sniffing for undocumented API methods.

If the API endpoint returns more info than required and relies on the fronted developers to filter the extra data, that basically means that for an endpoint like this—http://domain.com/users/user1—that should return some basic details like username, email, and last login date, and the server returns additional data like a full name and address.

The server relies on the front-end developers to filter out the unwanted information and present in the browser/app only the basic details that should appear there. However, the attacker can use the browser's developer tools or do an API request with an external tool (like postman) and see the full data that the server returns. So, where a regular user will see something like this

HTTP/1.1 200 OK { "user: { "username": "john doe", "email":"johndoe@gmail.com" } {

the attacker will see the full output:

HTTP/1.1 200 OK { "user: { "username": "john doe", "email":"johndoe@gmail.com", "name: John Doe Smith", "address": "Smith's road 1, NY, NY" } {

Protecting Against Excessive Data Exposure

What makes data sensitive and what manifests excessive data exposure is highly context-based. What constitutes excessive data in one API is a perfectly reasonable response from a different API.

Thus, it means that automated tools usually can't help you with identifying and mitigating this vulnerability. It's up to the developer to harden the API to protect against this vulnerability.

Vulnerability Mitigation

First, I'll provide some general guidelines for mitigating this vulnerability. After that, I'll provide some Java Spring-specific examples.

1. Never Rely on the Front End to Sanitize Data

The back-end developers that implement the API should be the ones that return only nonsensitive data. You shouldn't rely on the front end to filter out that data.

Even if front-end developers properly filter out the unwanted data, as seen above, an attacker can access the whole response by accessing the API independently.

I'll provide an example of how to avoid returning excessive data in an API response in Java Spring in the next section.

2. Protect API Endpoints That Require Authentication and Authorization

As I've described, you should protect with authentication and authorization each API endpoint that should return sensitive data.

3. Don't Expose All API Endpoints Via HATEOS

If you implement HATEOS as part of your REST API, don't return the whole list of API methods. Hence, return only a list of those methods that are relevant for the specific endpoint.

Spring Boot

The Spring framework is a superb Java framework for creating web applications and enterprise applications.

In 2005, Pivotal developed the Spring framework, and it's still very popular today. Ever since Pivotal developed the Spring framework, they've added various modules to the core Spring container.

Spring Boot is one of the most commonly used ones, representing the convention over configuration part of the Spring framework. Spring Boot lets you code with very minimal configuration.

Mitigating Excessive Data Exposure Vulnerability in Spring Boot

Let's return to the API example of a user endpoint discussed earlier:

HTTP/1.1 200 OK { "user: { "username": "john doe", "email":"johndoe@gmail.com", "name: John Doe Smith", "address": "Smith's road 1, NY, NY" } {

We can represent it in Spring Boot using the following class:

public class User { private String username; private String email; private String fullName; private String address; }

As I mentioned earlier, we want the API to respond only with the username and email. To do this, we can add the @JsonIgnore property to the fields we want to exclude in the API response:

public class User { private String username; private String email; @JsonIgnore private String fullName; @JsonIgnore private String address; }

This prevents the fullName and address from appearing in the response.

Conclusion

APIs are the backbone of many applications and websites. They provide critical services to clients.

Excessive data exposure vulnerability is a serious vulnerability that can pose a security risk to an organization. In this post, I've shown the way that this vulnerability is exploited and different attack vectors.

Likewise, I've added some standard ways to mitigate it, with a specific example for Java Spring Boot. Founded in 2005, this is a very popular framework for creating Java back-end applications, and it's still one of the most popular frameworks in the Java world.

Don't rely on the front end to filter out sensitive data; instead, manually go through your endpoints and make sure that you return only the necessary data.

In addition, avoid providing links for all the methods in the API, unless you're building an API documentation and, in general, harden your API as much as possible.

This post was written by Alexander Fridman. Alexander is a veteran in the software industry with over 11 years of experience. He worked his way up the corporate ladder and has held the positions of Senior Software Developer, Team Leader, Software Architect, and CTO. Alexander is experienced in frontend development and DevOps, but he specializes in backend development.

Java Broken Authentication Guide: Examples and Prevention

StackHawk

Authentication is one of the key policies of any application. This policy can control and protect the resources from unauthorized access. But if not implemented properly, it can result in multiple security vulnerabilities.

Java has held up great through the test of time. It's been around since 1996 and has been reinvented periodically to keep up with programmers' needs. It's one of the most widely used languages and has its share of vulnerabilities in authentication.

By the end of this post, you'll be able to understand the underlying problem and its actual impact, along with how to prevent it.

What Is Broken Authentication?

Broken authentication is a broad range of security vulnerabilities that occur due to poor implementation of an authentication mechanism.

Broken authentication occurs when a hacker or cybercriminal can bypass the authentication process in any possible way. This allows unauthenticated access to a system or, in some cases, allows the attacker to authenticate without providing a valid password or PIN.

For example, if a cybercriminal successfully obtains a username from a victim but the authentication system doesn't have any rate limit in place, the attacker can bypass the authentication by brute-forcing the password.

There are many different methods attackers can use to exploit broken authentication vulnerabilities.

Depending on the type of vulnerability and how it's exploited, attackers may be able to access sensitive data, change data, and much more.

What Leads to Broken Authentication Vulnerabilities?

Broken authentication can cause many problems such as data leakage and system compromise. Various reasons lead to broken authentication, including

using a guessable session ID,
having a session that doesn't expire after a password change,
using weak and well-known passwords,
have a lack of brute-force protection, and
storing sensitive data (passwords) in clear text.

But these are just vulnerabilities; how do hackers exploit these issues? Let's dig into that.

Common Attacks to Exploit Broken Authentication Vulnerabilities

When a hacker finds a vulnerability in a website's authentication system, they'll try to exploit it and retrieve sensitive data. But what exactly does the hacker do when it comes to exploiting the vulnerability? Here are three different types of attacks hackers use to exploit broken authentication vulnerabilities.

1. Brute-Force and Dictionary Attacks

A brute-force attack is the simplest type of attack. It's a trial-and-error method where the hacker tries to guess the target user's credentials. The attacker can use several techniques to do this.

On the other hand, a dictionary attack is the most common method and is simply a trial-and-error method to guess the user's password by using a wordlist.

2. Password Spraying

Password spraying is one of the most common attack methods. Oftentimes, it's used in conjunction with bots. This attack involves repeatedly attempting to log on to a server or website with a username and password combination.

The advantage of password spraying over a brute-force attack is that it's often successful. This is because it takes advantage of a common password used by many users.

3. Response Manipulation

Response manipulation exploits vulnerabilities in the communication channel between a server (or any other host) and a client. This happens when the application relies on the successful response (only boolean) of the server to validate a user. Additionally, an attacker can easily manipulate the incoming response using proxy and bypass authentication.

Also read: React Broken Authentication Guide: Examples and Prevention

Now that we've looked at broken authentication vulnerability in general, let's understand the vulnerability specific to Java.

Understanding Broken Authentication in Java

In this section, we'll look at three different code snippets (Java Spring Boot) and understand broken authentication vulnerabilities and how you can prevent them.

Let's get started.

Code Snippet #1

In the code snippet above, we have a /register endpoint that receives an email address and password from the request body. The security risks in this code snippet are:

Weak password policy—There is no check on the length of a password or even to check if the password is strong enough.
Cleartext storage of sensitive data—A password is stored directly in the database without hashing or salting the password.

To prevent the issues mentioned above, we recommend you have a helper function to check if the password is strong and to salt the password before storing it in the DB.

Code Snippet #2

In the code above, we have a /changePassword route that takes currentPassword and newPassword as input and changes the user's password by updating it in the DB. This code has an improper session management vulnerability due to which the session would not expire after the user changes his password.

To prevent this issue, the application should log out the user from all other active sessions.

Code Snippet #3

In the code above, we have an admin route /admin/user/data responsible for retrieving all of a user's data. The security risk in this code involves the lack of API authentication to check a user's authenticity and validate whether the authenticated user is admin.

To prevent the issue above, we recommend you add an authentication check and a proper authorization check (if the user is an admin) to avoid a data breach.

Now that we thoroughly understand the vulnerability, let's take a look at some common best practices to avoid such risks.

Best Practices to Avoid Broken Authentication Vulnerabilities

Broken authentication vulnerabilities are a huge problem for all applications, including mobile, web, and iOS.

Furthermore, account takeover attacks are responsible for a significant portion of the damage done to web applications and often involve broken authentication vulnerabilities.

Here are some best practices to help you avoid broken authentication vulnerabilities in your applications.

Enforce a strict password policy. Above all, creating longer and stronger passwords is the first step to avoiding broken authentication vulnerabilities. To enforce a strict password policy, you need to either use LDAP and Active Directory to manage your authentication credentials, or use a password management tool like LastPass, DashLane, or 1Password.
Require multi-factor authentication. Multi-factor authentication is a very effective method of preventing unauthorized access to your systems. This approach, in combination with a username/password pair, is highly recommended for systems that access sensitive data.
Use rate limiting. One of the best ways to avoid authentication attacks is to use a rate limit on all authenticated related endpoints such as login, which prevents brute-force attacks. Modern-day applications use two different ways to implement rate limitations. First, they can block the user's account after he has tried to log in several times with an incorrect password (known as account lockout). Second, they can stop an attack using a CAPTCHA image challenge. Although these CAPTCHA challenges were annoying and difficult to decipher in the past, nowadays, with advances in computer vision, OCR, etc., this is becoming less effective.

Conclusion

Broken authentication vulnerability is a major threat to a system's security. For example, it can result in a loss of confidential information, loss of reputation, and financial loss. Moreover, the severity of this vulnerability is usually very high, as the unauthorized user can access the system and its resources. Consequently, this may lead to the theft of an organization's data and sensitive information.

In this post, we've discussed broken authentication vulnerability in-depth and learned how hackers can exploit it. Furthermore, we've learned some preventive measures you can take to protect your applications from such attacks.

Scanning for broken authentication vulnerabilities using StackHawk DAST is a breeze! For more information, don't hesitate to contact us at hello@stackhawk.com.

This post was written by Keshav Malik. Keshav is a full-time developer who loves to build and break stuff. He is constantly on the lookout for new and interesting technologies and enjoys working with a diverse set of technologies in his spare time. He loves music and plays badminton whenever the opportunity presents itself.

Java Broken Object Level Authorization Guide: Examples and Prevention

StackHawk

Broken object-level authorization (BOLA) happens when a user has the ability to gain access to information that only a system administrator should see. This means that attackers have access to sensitive resources, like confidential user data or business secrets. It results in catastrophic security breaches. So, web application developers need to understand this security problem and how to avoid it.

This article will discuss broken object-level authorization (BOLA) problems in Java applications. Then, we'll look at a few examples and how you can fix and prevent the problem.

Broken Object Level Authorization

Broken object level authorization happens when an application fails to check a user's entitlements before granting them access to information. As a result of application developers failing to control access to individual resources, authenticated users are able to retrieve, modify, create and delete information that they shouldn't.

There are plenty of third-party services and libraries for authentication, but the responsibility for verifying access control at the object level falls to the application. This check is often based on user information provided by the authenticator, but using that information for performing a final check is the responsibility of the app code.

These bugs are easy to exploit since all the hackers need are a set of credentials and a script to retrieve the data. So once an attacker discovers a BOLA problem, they exploit the application very quickly.

A Broken Object Level Authorization Example

A Simple API

Consider a website that stores user information using a simple RESTful API. Here's a simple JSON definition of a web site user:

{ "id": 1, "fullName": "One More Person", "jobTitle": "Yet Another Title", "email": "foo@example.com" }

The application offers typical CRUD endpoints:

GET /people/ with no argument retrieves a list of all users.
PUT /people/{ID} with a JSON record updates an existing user with new information.
POST /people/ with a JSON record to add a new user.
GET /people/{ID} to retrieve a user by Id.
DELETE /people/{ID} deletes a user.

A BOLA API Issue

Leaking personal information about users can result in serious civil and legal consequences. So, managing user information requires extra care. Depending on the nature of the application, there may be reasons for users to see information about each other. But, even that requires extra care.

So at a minimum, the website should provide object-level authorization like this:

Site administrators can add new users, update their information, and delete them.
Users can update their own information and remove themselves.
Users can retrieve each other's information.

Item #3 may or may not be appropriate based on the site. The rules governing access to user access are beyond the scope of this article. Depending on the type of information, providing users access to each other's data may be a case of Excessive Data Exposure.

Regardless of the details, checking to see if a user has a valid session isn't enough. The application needs to verify that a user is valid and then ensure that they are allowed to complete their request.

Java Broken Object Level Authorization

Sample Java RESTful API

Let's look at an application based on the sample code included in Dropwizard's GitHub repo. In order to support this tutorial, I've made a few small modifications. So if you pull the code from Github you'll see some differences.

Here's a modified version of the example PeopleResource class. All the endpoints defined above are implemented in this class, and the users must authenticate with Basic Authentication to access the endpoint.

On line #3, the @RolesAllowed() annotation limits access to these endpoints to authenticated users with the BASIC_GUY role. As a result, the user must be authenticated before they can access any methods in this class.

This role is defined here:

Unauthenticated users have no role. The user named "good-guy" has the BASIC_GUY role. The "chief-wizard" user has both the ADMIN and BASIC_GUY roles.

Java Broken Object-Level Authorization in Action

Let's take this example for a test drive.

Here's the log of an unauthenticated request with Postman.

Unauthenticated users can't view users. That's what we'd expect.

Let's try with the "good-guy" login.

That user is able to view users.

Let's update that user's email.

That worked, too. "Good-guy" can modify users.

The same account can add them, too.

The code limits access to the PeopleResource class to members of BASIC_GUY. As a result, members of that class can call all of its endpoints.

But, this class has BOLA. Any user with access to the application can not only view user information but can modify, add, and delete them, too.

So, how do we fix this?

Fixing Java Broken Object-Level Authorization

You fix Broken Object-Level Authorization by adding explicit authorization for privileged operations.

The first step is to identify the operations to which we don't want BASIC_GUYs to have access. For our sample application, that's easy. Only members of ADMIN should be able to add, modify, and delete users.

Dropwizard makes this easy. We can add the @RolesAllowed() annotation to methods, too.

First, let's limit the ability to add new users to ADMIN first:

@POST @UnitOfWork @RolesAllowed("ADMIN") public Person createPerson(@Valid Person person) { return peopleDAO.create(person); }

Now, we'll try to add a new user as "good-guy":

Perfect.

Next, let's try as "chief-wizard." You can see in the log that the encrypted Authorization token holds a different value:

The API request succeeded.

But can "good-guy" still see the new user? Here's the request with the original token:

"Good-guy" can still list users.

So, we can finish the job by adding the annotation to updatePerson and deletePerson.

Avoid Java Broken Object-Level Authorization

In this article, we've looked at Broken Object Level Authorization and how it can lead to serious data compromises. We saw how application design that doesn't address access control on the object level allows unprivileged users to add, remove and update the information they shouldn't be allowed to. Then, after an overview of the problem, we looked at sample java code that BOLA. After that, we addressed the issue by adding object level authorization where it was needed. Dropwizard and most Java frameworks have the mechanisms you need to address this serious problem.

Laravel Excessive Data Exposure: Examples and Prevention

StackHawk

Excessive data exposure is when an API responds to a request with more data than required. Superficially, it looks like a design flaw. In reality, OWASP Lists this problem as one of the top three API Security threats. If an attacker discovers a method that returns the right fields, they can use an unprivileged account to retrieve the data. As a result, these vulnerabilities can lead to serious data compromises, including leaking user data and creating legal liabilities.

This post will look at the nature of excessive data exposure and how you can protect yourself in Laravel applications.

What Is Excessive Data Exposure?

Many mobile and web apps request API data, receive a superset of the fields they need and filter the results based on what they want to display. So, the application design implicitly relies on the server returning all of its data for a given entity.

For example, consider a typical e-commerce website. It stores client information, including names, emails, and addresses. Here's an example API request for user Id #5 and the response.

This request for user Id #5 returns all of the available fields for the user, including the hashed password and an API token, two fields that no display application should even need.

The architecture behind this application expects the display to use the fields it needs and discard the rest. But filtering data in display apps doesn't mean it's not visible. Any application with access to the API can retrieve this excess data, too. So, an attacker with a compromised password or even a spoofed account that has access to user records can retrieve all their information.

Protecting Laravel Applications From Excessive Data Exposure

In the example above, we retrieved information for a user by Id. This idiom is typical in "CRUD" APIs, where applications request the data they need and display the relevant fields based on context.

The response came from a Laravel server. Unfortunately, getting the application to return the excess data didn't require any extra effort. Quite the opposite: the code was from a Laravel RESTful API tutorial.

A Simple RESTful API

Laravel makes it easy to connect a web application to a database.

Most web frameworks advertise this as a feature, and they're right. Instead of writing boilerplate database access code, the framework generates it for you, and you can get to work on your business logic. Laravel does this with its Eloquent ORM. But, from a security standpoint, you might say that its design is optimistic.

The sample code used above has a user object with basic fields for user name, email, address, and basic authentication.

Here's the SQL table that stores the users:

When we give Laravel an empty model class, it figures out how to add, update, retrieve, and delete users from this table for us.

So, here's the model:

class User extends Model { }

And here's the controller (with the authentication code removed:)

This code needs a few routes (that we don't need to see here), and we have a working API.

But as we saw above, the default behavior is to return all of the fields in the model. This is true for any model that uses the default code.

The good news is that there are a few ways to make this code more secure.

Move Your Fields to a Different Table

If your application uses a SQL database, you might consider moving the fields related to authentication to a different table and giving them their own model. Separating concerns this way makes sense from both an architectural and maintenance standpoint. It'll be easier to update your authentication model in the future and often makes your code easier to read.

But if you're using a NoSQL database or have inherited a "mature" codebase, this might not be possible.

Filter Your Fields From JSON

The default model code is generating a SQL query that looks something like this:

select * from users where id=5

If we were writing the application by hand, we would probably consider rewriting the query to only select the fields we need. We could take that approach now and modify the model to use a similar query.

But, that would create some new problems. While the display applications should never see hashed passwords, the authentication system needs them. As soon as we started crippling the model, we created the need for multiple interfaces or even a second model for the back end. As a result, we'd only add a new set of maintenance issues.

Laravel addresses this problem by making it possible to retrieve all the data from the data store while hiding the excess data from JSON. As a result, it's easy to prevent API clients from seeing certain fields while still making them accessible to backend model users. You do this by adding a $hidden field to the model class.

Let's hide the password field:

class User extends Model { protected $hidden = ['password']; }

Now, we rerun the query for user #5:

Laravel omitted the password field from the response.

The $hidden field is an array, so you can use it to filter out all of the unwanted data.

class User extends Model { protected $hidden = ['password', 'created_at', 'updated_at', 'api_token', 'remember_token', 'email_verified_at' ]; }

Now we have a simple mechanism for ensuring the no display application sees critical backend data:

That Which Is Not Explicitly Permitted Is Denied

The $hidden field hides fields by name. It's a powerful tool, but it might not be enough. Web code moves fast, and you may inadvertently add a new field to your model and forget to hide it.

A safer security model is to define a set of fields that are allowed and only pass them to API users.

The $visible field defines the fields that are available to JSON. Laravel will not provide fields missing from this array to API requests.

Let's list name and email as the only visible fields:

class User extends Model {

protected $visible = ['name', 'email']; }

Then run a query.

GET http://localhost:8000/api/user/5

{ "name": "Joe Customer", "email": "joe@example.com" }

That's nice and clean!

So, we have two robust mechanisms for filtering backend information from display clients and potential hackers. Depending on how you want to address the problem, you can either list the fields that are visible or hidden.

Filter Laravel Fields to Avoid Excess Data Exposure

We've looked at the problem of excess data exposure and how it can compromise your application's security. Laravel's robust model-viewer-controller features make it easy to put a RESTful API together, with a small amount of code. But, its behavior isn't always what you want or need. We saw how the default model provides all available data to requestors. Then we looked at the tools Eloquent provides to make filtering fields from API request easy.

So, you have the tools you need to address Excess Data Exposure in your Laravel code. It's time to take the next step: StackHawk has the tools you need to keep your code and your clients safe. Sign up for a free account and see how!

Django Excessive Data Exposure: Examples and Prevention

StackHawk

We can perform all kinds of activities online, such as shopping, internet surfing, reading books, banking, and more. But have you considered how we're able to receive so much information? It’s possible thanks to Application Programming Interfaces (APIs) that enable data sharing between an application's different entities. Even though tasks are easy to accomplish with the help of APIs, we still have to deal with security issues. Is the data that's shared over the internet secure? What if it's hacked? This brings us to excessive data exposure. In this article, we'll define what it is, explain how it can be harmful, and cover it in one of the Python frameworks, Django.

What Is Excessive Data Exposure?

When you build an application, there are certain data requirements. Some applications require real-time synchronization. In every application, you generally want to have access control over the data. But there are scenarios where there is no control over specific information, which causes excessive data exposure. Excessive data literally means extra data. Sometimes the client gets access to more data than what was requested. Exposing this extra data causes security and privacy issues. Sensitive information is prone to be leaked during communication, and hackers can easily take advantage. Let's look at the cause of this vulnerability.

What Causes Excessive Data Exposure in Django REST?

An API is responsible for communication between software or websites. REST has been the standard way to design various web APIs, but it comes with some weaknesses, including the over-fetching of data. Over-fetching simply means that the client downloads more information than required. Hence, it becomes vulnerable as the data can be leaked or hacked midway. How does this happen? REST functionality doesn't give power to the front end to generate specific endpoints for the requested data. When the client requests data, the API sends the request to the server, and all the related information is passed to the client as a response. Therefore, the client gets a response with extra data that can possibly lead to data leakage. Let's look at this problem using an example.

Example Use Case

Consider a fashion store that has online services. Customers purchase outfits from the website by first logging in and submitting some relevant information. While purchasing, they use internet banking services where the data is stored on the server. Now, say the store is running a marketing campaign that requires information about its customers for further analysis to improve its sales. Let's say it needs the names and addresses of customers from the database on the server. It would send the request below: https://apparel.com/api/customers/show?customer_id=1 The API would then send the request to the server and generate a response. The information given includes all the information about the customer.

The above data contains certain confidential information. If exposed, it can create a big problem. Therefore, you'll need to remove the excess data before it reaches the client. If you want to dive deeper into this vulnerability, you can find a detailed guide on it here. Now let's discuss some of the techniques that can prevent excessive data.

How to Prevent Excessive Data Exposure in Django

There are various ways to deal with data exposure.

The client should not be responsible for filtering data. Hackers can easily get a hold of data at this stage. But if the server side filters the information, you can prevent this. If, on the other hand, you need to gather all this information, you should mask the data.
Encrypt the data during the transfer of information from one end to the other. If the data is leaked, the attacker won't be able to decrypt it.
Automate APIs using various security tools so they'll be alerted whenever something like this occurs.

Next let's look at how excessive data exposure can occur in a REST API and how to fix it.

REST Application in Django

First, let's create a simple REST API in Django.

Create a New Django Project

In order to create a new Django project, run the following command inside a directory of your choice:

django-admin startproject user

Next, jump into the project directory. This is where you'll create a new Django application that consists of user information.

django-admin startapp info

Create Models in Django

Models are the objects in Django that perform basic REST functionalities like create, update, read, and delete (CRUD). To do that, open the models.py file in the info directory and add the following code:

Then open admin.py file and register the data models as shown below:

from django.contrib import admin from . models import user_info # Register your models here. admin.site.register(user_info)

Finally, migrate these models into the database using the following command:

python manage.py makemigrations python manage.py migrate

Run the Server

To run your Django server, use the following command:

python manage.py runserver

You should see the following update on your terminal.

Now let's see what the application looks like.

Creating a Superuser

It's time to create a superuser that will allow access to the admin page.

python manage.py createsuperuser

Then enter a username and password.

Django Administration

Now go to the admin page to add some data to the database by adding add /admin to the following URL: http://127.0.0.1:8000/admin The page should look like this:

Next, input your credentials to enter your admin page with access to the database and start adding data to your table.

Serialization

After adding all the required data, create a serialize.py file in the app directory. This will help translate the objects into data types in order to view them in formats like XML, JSON, etc., as a response.

Views in Django

The view is an important component in Django. It allows clients to make requests and generate a response. Hence, this component makes the required endpoints. So update the views.py file.

Final Output

The last step is to create the URL to view the JSON data, i.e., the user list. The urls.py of the main project should contain the following code:

You can check the final result by clicking the URL http://127.0.0.1:8000/user.

The API returned all the data from the database. But what if you want only some data? Django can return only the data a client wants after removing all the extra. Let's check it out.

Django RESTQL

RESTQL is a package in Django that provides only specific data as a response from the server to the client. To import this package, first install it on your system.

pip install django-restql

In order to work with this package, the serialize.py file will require some changes.

The package allows querying the data according to the requirements of the client. The response generated in the REST API consisted of all the data fields. Let's suppose the client only wants to see the names of the users, meaning that data in other fields like ID and phone number are extra. In order to handle this, you can add the query to the URL.

http://127.0.0.1:8000/user/?query={firstname, lastname}

You can see in the figure above that the output contains only the users' first and last names. This is how you can eliminate access to extra data and block an attacker's entry.

Conclusion: Preventing Excessive Data Exposure in Django

With RESTful APIs, you have to carefully structure your responses and database queries so that you don't accidentally send sensitive information back in the API. Filtering your back-end APIs according to what data the client requests will go a long way toward helping you avoid excessive data exposure.

This post was written by Siddhant Varma. Siddhant is a full-stack JavaScript developer with expertise in frontend engineering. He’s worked with scaling multiple startups in India and has experience building products in the Ed-Tech and healthcare industries. Siddhant has a passion for teaching and a knack for writing. He's also taught programming to many graduates, helping them become better future developers.

StackHawk Raises $20.7 Million in Series B Funding

StackHawk

DENVER, Colo. - May 12, 2022 - StackHawk, the company making application security testing part of software delivery, has secured $20.7 million in capital co-led by Sapphire and Costanoa Ventures, with participation from Foundry Group and other high-value investors. With this funding, StackHawk will invest in product development to maintain its market leading position in developer-first application and API security testing. This latest financing brings StackHawk’s total funding raised to $35.3 million.

Every modern software development organization has shifted from quarterly releases to daily or hourly releases, incorporating Continuous Integration and Continuous Delivery (CI/CD). In the modern world of FinTech, HealthTech, cloud analytics and AI platforms, customers are entrusting their most critical data to software providers. Periodic manual security testing by an external team is simply too risky. Because of this, modern software development organizations are extending CI/CD to encompass Continuous Application and API Security Testing. This way, security can “shift left,” meaning vulnerabilities can be detected while the developer is actively working on the code.

Forrester reports that web application and API exploits are the most common form of external attack affecting organizations today. To better protect from these threats, 43% of global security decision makers are looking to implement dynamic application security testing during software development. As a result, Gartner expects worldwide application security testing (AST) end-user spending to exceed $3.1 billion in 2022, which presents a massive opportunity for StackHawk.

“Security has never been more important than it is today. Organizations of all sizes across all industries know that they have a gap in how they approach security, and they are recognizing the need for what we do even before we speak with them,” said Joni Klippert, Co-Founder and CEO. “As the leader in advanced dynamic security testing, the market pull for our solution drove the funding round. We will use the new capital to continue to invest in our product, grow our leadership team and significantly increase funding for marketing, sales and partnerships. Our recently announced Snyk integration, which is already driving value with joint customers, is a great example of this.”

“There is a serious gap for modern tooling that helps teams efficiently deliver secure applications. In the same way CI/CD has revolutionized how developers deliver quality applications, StackHawk is ensuring security testing is an extension of the process, making security part of the code quality discussion for developers,” said David Hartwig, Partner at Sapphire Ventures and a Board Director at StackHawk. “Sapphire is excited to have seen the value in providing developer-first application and API security testing early on, leading StackHawk’s Series A. We are proud to reaffirm our commitment to StackHawk with this round as we feel Joni, the team and product are set to thrive in this high growth market.”

“StackHawk’s track record of delivering is what made us want to co-lead this round. The executive team’s blend of expertise across security and DevOps has created a tool that every developer will need,” said Greg Sands, founder and managing partner of Costanoa Ventures. “From our experience investing in high-growth software companies, we know security is no longer optional. Finding modern security tooling is top of mind for today’s engineering leaders, especially for those in highly-regulated industries with strict regulations and compliance standards for data protection.”

To learn more about the funding round and StackHawk’s approach to developer-first application and API security testing, visit stackhawk.com. To see open roles at StackHawk visit stackhawk.com/jobs.

About StackHawk

StackHawk is making application security testing part of software delivery. The StackHawk platform empowers engineers to easily find and fix application security bugs at any stage of software development. With a strong founding team that has deep experience in security and DevOps, and some of the best venture investors in the business, StackHawk is putting application security testing into the hands of engineers. Learn more and sign up for a free trial at www.stackhawk.com.

About Sapphire

Sapphire is a leading global technology-focused venture capital firm with more than $10.2 billion in AUM and team members across Austin, London, New York, Palo Alto and San Francisco. For more than two decades, Sapphire has partnered with visionary management teams and venture funds to help scale companies of consequence. Since its founding, Sapphire has invested in more than 170 companies globally resulting in more than 30 IPOs and 45 acquisitions. The firm’s investment strategies — Sapphire Ventures, Sapphire Partners and Sapphire Sport — are focused on scaling companies and venture funds, elevating them to become category leaders. Sapphire’s Portfolio Growth team of experienced operators delivers a strategic blend of value-add services, tools and resources designed to support portfolio company leaders as they scale. To learn more about Sapphire, visit: https://sapphireventures.com.

About Costanoa Ventures Founded in 2012, Costanoa Ventures backs tenacious and thoughtful founders who change how business gets done. Costanoa invests early, starting at company formation, with a focus on apps and infrastructure in data, dev, fintech, and Web3. Costanoa is a long-term partner to entrepreneurs who want hands-on help in their earliest company stages. For more information, please visit www.costanoavc.com.

Proudly Announcing StackHawk’s $20.7 Million in Series B Funding

Joni Klippert

Following up on the announcement of our partnership with Snyk in April, we are delighted to announce another big day for StackHawk.

We have secured $20.7M in fresh capital co-led by Sapphire and Costanoa Ventures, with participation from Foundry Group and other investors and long-time believers in StackHawk. This latest financing brings StackHawk’s total funding raised to $35.3 million.

With this funding, we have the opportunity to ramp up investment in product development and capitalize on a market that is desperate for a better way to approach application and API security testing.

Let’s Rewind

We started StackHawk nearly three years ago now when DevOps tooling and processes were beginning to mature. At that time, there was great concern about how security teams were going to keep up with the pace of software delivery. Dynamic application security testing (DAST) was a desired technology (I can’t tell you how many times I heard “if you could only automate DAST!”), yet a second class citizen that was hamstrung by its old reputation of taking multiple teams to deploy, days to run, and producing a PDF of results that just weren’t that helpful.

I was a Vice President of Product who had experienced this pain first hand. Security issues would get dumped on my plate and marked as top priority fixes. I had to make a decision about interrupting sprints and delaying feature releases versus fixing security issues which often lacked context.

I knew the way security testing worked was fundamentally broken, and in July of 2019, we put together the team to deliver on a product and GTM motion to fix it.

An Evolving Market, Three Years Later

Now, three years later, we are in a market where security has never been more important, and organizations across industries of all types and sizes are rapidly changing how they approach security.

No longer are technical decision makers looking for security tools that can only find security issues after code has been shipped to production. Instead, the market is demanding solutions that make application and API security testing part of software development.

43% of global security decision makers are looking to implement dynamic application security testing during software development as they try to keep their most critical data safe.

StackHawk has proven that security doesn’t have to be an “either/or'' decision with feature delivery. We bake security testing in from the start which has a massive impact on the quality of the code being shipped to production. Transforming how teams identify and fix application and API security issues is the mandatory next step in making software delivery efficient, while driving quality.

Now is the time to accelerate product investment and extend our leadership in what the market is demanding:

Continuous Security Testing in CI/CD: Continuous Integration/Continuous Delivery (CI/CD) has become a mainstay in modern software development organizations. StackHawk extended this to include Continuous Security Testing baked into existing DevOps pipelines, with security issues being surfaced and fixed early in the software delivery lifecycle, just like any other bug.
Coverage of Modern Application Architecture: Today’s software is generally built on a microservices architecture, with the most sensitive data often accessed at the API layer. StackHawk conducts traditional web application testing like other players in the market, but has also built market leading API security testing functionality for REST, SOAP, and GraphQL APIs.
Correlation and Actionability: StackHawk is built for developers to own the security testing of the code they write. When issues are found, StackHawk makes it simple for a developer to fix the issue. With the recently released integration with Snyk, not only are developers equipped natively in StackHawk to debug, but they can also see correlations to Snyk Code findings to identify which line of code contains the vulnerability.

Looking Ahead

We are building StackHawk to be the de-facto choice for developers that need application and API security testing. The world of security is fundamentally changing and the market is demanding new solutions that legacy vendors simply can’t provide.

Beyond investing in product, we are laser-focused on making it much easier for developers to hit the ground running with StackHawk. From our CLI that we introduced earlier this year, to new product integrations, the developer-experience is front and center of what we will deliver moving forward.

Growing the Nest

If you want to learn more about StackHawk, watch a demo on demand here.

We have also completely revamped our onboarding experience to provide users with all they need to get automated security testing stood up quickly. Sign-up for a StackHawk account and get scanning.

And, if you want to work with the greatest humans imaginable, check out our jobs board and see the openings we have across our team.

This is only the beginning, and I look forward to sharing our success with all of you today and in the exciting future ahead.

What Is Open Redirect?

StackHawk

Open redirect attacks are a growing issue in web applications nowadays, as there are many serious vulnerabilities open redirects can lead to. As applications increasingly use external data sources, there's an increasing need to secure URL redirection.

In this post, we'll go over what exactly open redirect is, how this attack works, how you can detect it, and how you can prevent it.

What Is Open Redirect?

Before understanding what open redirect is, let's learn what redirect exactly means.

A redirect is an HTTP response code that sends a user agent to a different URL from the one requested. Hackers use redirects for many reasons, including to implement a change in the structure of a website, to pass a user agent to a different website, or to serve the same content under multiple URLs. Still, if they're not implemented correctly, redirects may lead to open redirects.

Open redirect is a vulnerability that can be used to manipulate the application to redirect users to a different URL other than the one that's intended. This can be done by manipulating the URL to include the parameters that redirect the user to a different URL. This is one of the most common vulnerabilities found in most applications.

Open redirect vulnerabilities may result from insecure input validation on a website or a service that allows for parameter tampering. By performing a redirect, attackers can steal users' credentials, redirect users to phishing sites, and do more malicious things.

Types of Open Redirect

Open redirection (open redirect) is classified as one of two types: header- and JavaScript-based, also known as type I and type II open redirect.

1. Header-Based Open Redirect Vulnerability

This type of open redirect is achieved through the HTTP response headers, which can be easily abused because of their multipurpose use.

For example, the location header redirects the user to another location or resource. Still, an attacker can also use it to redirect the user to a malicious URL. Then, the attacker can use the location header to send the user to a phishing website by manipulating the URL to redirect the user after the authentication process.

2. JavaScript-Based Open Redirect Vulnerability

Industries use JavaScript to develop applications (both front end and back end). A web application's failure to validate the request URI before redirecting to an unintended destination can lead to this type of open redirect. Based on the scenario, this kind of issue can occur on either the front or back end.

Vulnerabilities That Arise Due to Open Redirect

A lot of people ignore the importance of addressing open redirection vulnerabilities. They think it's just a vulnerability that allows someone to redirect users to a different website. But hackers can use this vulnerability for much more.

Once a hacker finds and exploits this vulnerability, it's no longer just a matter of redirection. He can perform phishing attacks, cross-site scripting attacks, and even server-side request forgery attacks. Let's try to understand each of them one by one.

1. Phishing Attacks

Phishing attacks are the most common way for cybercriminals to steal users' credentials, and one of the most common attack vectors is the open redirect vulnerability.

2. Cross-Site Scripting Attacks

Hackers can use open redirect to execute XSS payloads by redirecting the parameter to JavaScript. The two most common payloads to convert open redirect to XSS are

javascript:alert(1), and
javascript://%250Aalert(1).

3. Server-Side Request Forgery

If the application sends HTTP requests to the redirect URL, open redirect can lead to server-side request forgery attacks.

How Hackers Exploit Open Redirect Vulnerability

Open redirect vulnerability is the most common way attackers perform phishing attacks.

Hackers carry out phishing attacks to steal your personal information like credit card details, username, password, etc.

When the user accesses a website with a vulnerable parameter, the attacker crafts a URL to redirect the user to a malicious website. The URL can look like the URL below with the vulnerable redirectURL parameter. Once the user opens the URL, he'll be redirected to https://example.phishing.com .

https://www.example.com/login?username=test&password=test&success=false&redirectURL=https://example.phishing.com

How Did the URL Redirect Happen?

In the URL provided above, example.com is a trusted domain, and redirectURL is the parameter that contains the URL where the user will be redirected after authentication. Two pointers make this URL perfect for phishing attacks:

The length of the URL is quite significant, which decreases the probability of the user reading the end part.
Users trust a URL after reading the trusted domain in the first part of it.

Once the user opens this URL, the application will redirect the user to the URL present in the redirectURL parameter.

The malicious website will ask for sensitive information like a username and password, just like the original website. Once the user has provided the credentials, the attacker will have access to the user's account.

In many cases, the user doesn't realize they've been redirected to a malicious website until it's too late.

Understanding Open Redirect With Example (Code)

Suppose you have a website that has an email verification endpoint component made in ReactJS.

In the example above, we have a functional component for email verification on /email route. The URL for email verification will look like this:

http://www.example.com/email?token=xyz&redirectTo=/dashboard

Once the user opens the email verification link, the component will validate the email verification token from the URL and redirect the user to the redirectURL parameter if the email is verified; otherwise, a redirect will occur to the /login route.

The code mentioned above is vulnerable to open redirect. If the attacker crafts a URL with a malicious redirectURL parameter, he can redirect a user without hassle.

http://localhost:3000/email?token=helloIamaToken&rediectTo=https://www.evil.com

To prevent open redirect in the code provided above, rather than using window.location.href, it's recommended you use the useHistory hook. The sample code looks like this:

In the code above, the user will be redirected to http://localhost:3000/https://www.evil.com even if the attacker tries to manipulate the parameter.

Furthermore, to add an extra layer of security, developers can create a helper function to check if a URL is a relative URL or not.

Now that we understand how open redirect happens, let's focus on a few things you should keep in mind to avoid open redirects.

3 Things to Avoid With Open Redirects

Open redirect is a fairly common issue on the web, so it's essential to keep these points in mind to avoid such risks.

Avoid redirect parameters in URLs, store them in localstorage, or use custom paths using code instead.
If you use redirect parameters, validate the supplied input (query strings).
Use whitelisting and validate if the URL is relative or not while implementing redirects.

Best Practices to Avoid Security Vulnerabilities

Security is one of the most important factors to consider while building a web application or website. It's the gateway to your customer's information or data. You must take every possible step to avoid security risks. Below is a list of best practices to prevent security vulnerabilities in your web application.

1. Always Validate User Input

User input is one of the biggest causes of security vulnerabilities. When an application takes user input and then blindly acts on that input, it opens itself up to a whole new set of vulnerabilities.

2. Keep Sensitive Data Out of Logs

Data in your logs should be the bare minimum. This means you should never log essential data like username, password, credit card information, etc. You can add data that helps with debugging and analytics. If you see data or information that can compromise security, then you shouldn't include it in your logs.

3. Use Always Deny Rule

The simplest way to think about this is that all access controls are denied if you don't explicitly allow something. If you can identify potential issues early on in the design of a system, you can prevent those issues from taking effect. It's easy to deny access to everything by default and then determine what access you need to allow.

4. Automate Testing for Security Vulnerabilities in the Build Pipeline

In the ever-changing web application development landscape, companies need to take extra steps to ensure that there are no security vulnerabilities in their web applications. Developers' primary focus is on the end product and not on the security vulnerabilities that may exist on the platform. This is where a security scanner like StackHawk comes into play.

StackHawk offers a DAST scanner that is integrated into a development pipeline.

A DAST scanner is a tool that scans for security vulnerabilities on web applications, both in the source code and in the deployed code.

It helps developers identify and fix security issues early on in the development cycle, ultimately saving development time, saving money, and ensuring a more secure end product.

Conclusion

Now that you've read our post about open redirect vulnerability, you should be aware of the potential dangers an open redirect vulnerability can cause and know how to protect yourself against such hazards.

If you have any questions about protecting yourself from such threats, our team can help you identify the issue and find the right solution.

What is Path Traversal?

StackHawk

Cyberattacks don't come in just one form or fashion. Cyberattackers use several different techniques and avenues to breach security. One of the most popular is path traversal. In this blog post, we'll cover what path traversal is and how it works. We'll also look at how you can avoid these kinds of attacks.

What Is Path Traversal?

A path traversal (or dot-dot-slash) attack is a malicious attempt to trick a web application into displaying the contents of a directory other than the one requested by the user and gain access to sensitive files on a server. For example, if a user should be viewing an image called abc.jpeg but the web application is tricked into displaying the files in /var/www, the attacker will have successfully performed a path traversal attack.

The attacker may be able to access files that should only be accessible to the web server's owner, such as .htaccess files or files containing configuration or authentication data.

What Kind of Security Breaches Can Path Traversal Result In?

Suppose a site is vulnerable to path traversal. In that case, an attacker will be able to read sensitive files, such as application source code containing usernames and passwords, database credentials, and even private encryption keys. Hackers will be able to write data to arbitrary files in some cases, allowing them to upload a back door to the site, to upload malicious files that are automatically executed, etc.

What Happens When a Path Traversal Attack Executes?

Path traversal is a method of accessing files and directories stored outside the webroot folder.

Using a typical example, let's look at how path traversal works under the hood.

Let's say a user is using an online shopping app that creates an invoice every time they shop. When accessing the invoice, the URL looks like this:

https://www.shopping.com/user/invoice?name=order1

The name here denotes the name of the PDF invoice that the server needs to send. When the server receives the file's name, it adds the working directory and the file extension to the name of the file (/var/www/invoices/order1.pdf), gets the file from the server and sends it back. If the attacker replaces the filename order1.pdf with something malicious like../../etc/passwd, the application will return the requested file's content if the proper controls are not in place.

What Conditions Are Required for a Successful Path Traversal Attack?

A path traversal attack is a type of attack that allows a hacker to traverse through directories and read or write any file on the system. A hacker can carry this out by exploiting insufficient input validation techniques. To be able to carry out a path traversal attack successfully, a hacker needs to meet any of the following conditions:

1. Lack of Relative Path Checking

The most frequently used technique to exploit the directory traversal vulnerability is to use a relative path appended to a vulnerable parameter. If the parameter is not sanitized correctly, the attacker can read arbitrary files from the system.

2. Validating File Extensions Only

File extension validation is a popular way to fix the problem. However, a lot of people miss how dangerous this can be. File extension validation is never a substitute for checking if the parameter is trying to access another file of a different format and can easily be bypassed using Null Byte at the end of the file.

3. Escaping Dot-Dot-Slash (Improper Implementation)

Some developers try to escape or replace only the ../ from the string, but this is not a proper fix, and it can be bypassed by encoding the escaped characters. In this case, the ../ can be encoded and passed via the URL (for example, from: http://www.example.com/?invoice=../../../../../../../../../tmp/xyz.txt to http://www.example.com/?invoice=../../../../../../../../../tmp/xyz.txt?%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/tmp/xyz.txt.).

Now that you understand the conditions required to perform a path traversal attack, let's look at different ways in which hackers can perform this attack.

Different Ways to Perform a Path Traversal Attack

A hacker can perform a path traversal attack by manipulating the file path on the webserver and exploiting its weak security.

Below are the most common methods:

1) Using a relative path. This attack adds a file or folder path relative to the current working directory. For example, if the current working directory is /home/user/public_html, an attacker can upload malicious code such as ../../../../../../../../../../../../../../../etc/passwd to access the /etc/passwd file.

2) Encoding escaped characters. This attack encodes special characters using URL encoding. For example, the attacker can use %2e%2e/%2f to add a / after every two dots.

3) Using a Null Byte attack: This attack uses a Null Byte (\x00) to bypass a path's regular validation. For example, the attacker can add \x00 in the directory name to bypass the validation by breaking the regular expression. This is also known as Null Byte injection.

Secure Code Snippets to Avoid Path Traversal Attacks

Though path traversal attacks have been around for a long time, they're still a viral attack vector. This is because they're easy to launch and can be applied in several situations.

Below are some JavaScript secure code snippets that can help you avoid such attacks.

1. Normalize the file path.

The code snippets above are for JavaScript, but what about other programming languages? Let’s look at some standard best practices to avoid path traversal vulnerabilities.

Primary Methods of Preventing Path Traversal

By now, you should have a pretty good idea of what a path traversal attack is. You know that it involves a malicious attacker trying to access a part of your website that should never be accessed.

Let's cover some of the ways you can prevent path traversal, secure your web server, and keep your web application safe.

1. Normalize the file path.

2. Avoid using high-privilege users.

3. Update the version of your programming language and web server regularly.

4. Escape special characters (even if you've already URL encoded them).

5. Try not to rely on user-supplied file paths.

Although path traversal is a critical vulnerability, it's not the only vulnerability that hackers exploit, so writing secure code is essential. Let's have a look at some helpful tips.

Four Helpful Tips to Avoid Security Vulnerabilities

Security vulnerabilities can be present in any software. However, web applications are more vulnerable because they're online. Therefore, keeping them secure is essential.

Here are four tips:

1. Keep Your Software Up to Date

One of the most essential best practices is keeping your software up to date and updating it as soon as a new patch is released.

2. Automate Testing for Security Vulnerabilities in the Build Pipeline

The build pipeline is a vital part of the DevOps process. It allows the development team to compile the newly developed code and push it out to the production servers. However, this process can be pretty vulnerable, especially if you haven't configured it correctly.

That's where theStackHawk's DAST Scanner comes in. You can integrate it with CI/CD pipelines, which allows you to automate the scanning process and discover vulnerabilities as early as possible, including path traversal, SQL injection, cross-site scripting, etc.

3. Enforce a Strong Password Policy

This is a simple step many businesses overlook.

Requiring complex passwords that an attacker cannot easily guess is essential.

If you haven't yet created a password policy for your business, you should do so immediately.

4. Use SSL Certificates

HTTPS is a protocol that encrypts data as it passes between a user and the server, ensuring that no one can intercept it.

Conclusion

We wrote this blog post to provide you with the most comprehensive yet easy-to-understand information about path traversal vulnerabilities and what you can do to fix them. We hope you've found it helpful and that you'll take advantage of StackHawk's DAST Scanner to make sure your application is free of this vulnerability. If you have any questions or concerns, don't hesitate to contact us. Thanks for reading!

Angular XML External Entities (XXE) Guide: Examples and Prevention

StackHawk

An XML External Entity (XXE) attack uses malicious XML constructs to compromise an application. Using an XML External Entity Attack, an attacker can steal confidential information, create a denial of service, or both. They're dangerous attacks that you need to consider when developing your applications.

Let's look at Angular XML Entities. We'll discuss why you should worry about these attacks and how you can protect your code from them.

What Is an XML External Entity Attack?

Injection Attacks

Injection attacks exploit code by supplying it with invalid data. When the target processes the data, it alters how it behaves, usually by retrieving data for the attacker or causing the application to fail.

Two things about the target application need to be true for an injection attack to succeed:

It accepts untrustworthy data.
It processes the data in a way that causes the application to misbehave.

XML External Entities

XXE Attacks are injection attacks with dangerous XML documents.

XML is a powerful language, and it's easy to craft a document to steal information or disable a target.

You build XML documents with entities. Each entity other contains or points to data.

An internal entity holds its data, while an external entity refers to data that may be located on another system or elsewhere in the document. These external entities are where the danger comes from. Let's look at a couple of examples.

Here's a document that uses a URI in an external entity. URIs are a superset of the URLs you see in HTML links.

This document defines an entity named xxe that points to the contents of http://www.example.com/login. So, when the XML parser sees a reference to the entity, like the one between the <bar> tags, it retrieves that URL and inserts the contents of that page.

Here's an example of a document that defines a text-based custom entity:

The lol1 entity contains the string lol ten times. As a result, the parser replaces lol1 with ten lols.

Let's see how attackers use these tools.

Crafting an XML External Entity Attack

Now, let's look at some examples of XXE attacks.

Retrieving Network Information

Above, we demonstrated an external entity that pointed at a web page on the Internet. But, they use URIs, which can point to nearly any network resources, including hosts inside a private network.

For example:

If 10.1.1.1 exists, is running a web server, and has a page named login, the XML parser will retrieve the page and place the contents in the XML document. If one or more of those things are false, the resulting document may contain a potentially useful error. Even if this attack fails, the hacker can learn a lot from it. They'll learn if the IP address is valid, if it's running a web server, and if the server has a login page. For example, a 404 error page would tell the attacker a lot about the target's internal network.

Stealing Files

URIs can point to files, too. We can use the same document to grab a list of users from the server running the target application with one small tweak.

Instead of inserting the contents of a web page, this attack inserts the contents of /etc/passwd in the resulting document. This attack works for any file that the application under attack has access to.

Denial of Service Via File Injection

Linux has special files that act as interfaces to devices and device drivers. If you point an XML document at the right one, you can disable an application.

The /dev/random file generates random numbers based on system noise, but it can't generate one until there's some noise to use. So, when an application reads from this file, the call may block: it doesn't return data until the system can generate a random number. This leaves the XML parser hanging until something happens. Send a few hundred of these malicious XML files, and you can bring the server to its knees.

Data Injection

Let's take a look at the first example again.

This inserts a login page from an external website. If the attacker controls that website, they can use it to harvest usernames and passwords. This is an example of using XXE attacks to inject malicious data. A hacker can inject data into a vulnerable system from anywhere on the Internet.

Denial of Service With Entities

We looked at an example of using entities to define text nodes above. That document was part of the billion laughs attack.

Here's the entire document:

If the parser replaces each lol1 with ten lols, and each lol2 with ten lol1s, etc., all the way up to an lol9 indicating ten lol8s, then this document is expanded to a billion laughs. The name isn't hyperbole!

Angular XML External Entity Attacks

Many people associate injection attacks with server-side applications, where the right attack can compromise data or take a web application offline. But client applications are subject to these attacks, where hazards like compromised servers, man-in-the-middle attacks, or rogue redirects can lead to malicious data. So, let's see how to protect Angular applications from XXE attacks.

We can't always protect our applications from untrustworthy data. But we can make sure that our code doesn't process the data in a dangerous way. Angular doesn't ship with an XML parser; you can load any javascript parser and use it to process documents in an Angular application.

The good news is, that if you use xml2js or sax-js, you're protected from XXE attacks.

They both default to ignoring custom entities or passing them through without expansion. Sax-js ignores them, and xml2js uses sax-js to process documents. If you do want to process some custom entities, you can install your own event handlers, too.

Let's look at a quick example of how xml2js protects us. Put the document that attempts to inject the login page in a file named foo.xml.

Run this code:

Here is the output:

undefined Done

The parser ignored the custom entities and treated the document as if it contained no data.

Now, make a small change to the code. Add the strict option to the parser constructor, and set it to false.

Run the code again.

Now the parser processed the custom entities but without expanding them.

{ FOO: { BAR: [ '&xxe;' ] } } Done

You can put the other examples in files and test them out, too. Stick with these parsers and keep your dependencies up to date!

Secure Your Apps From Angular XML External Entity Attacks

Angular XML External Attacks are serious threats that can compromise your applications and expose customer data. But, stick to the right XML parsers and you're safe.

Now that you understand Angular external entity attacks, you know how to keep your applications and your customers safe. While you're at it, sign up for a free StackHawk account so you can scan for more threats and take your security to the next level!

React Excessive Data Exposure: Examples and Prevention

StackHawk

Do you ever wonder what happens with all the extra data your server sends that the front end doesn't consume? Or what to do with all the extra information in the JSON object you get from your back-end APIs?

This scenario often leads to a potential vulnerability called excessive data exposure. The end result is that attackers can use the extra sensitive data that's exposed to do something harmful to your users. But what exactly is excessive data exposure? How can it be harmful? And how can you prevent it in your front-end React application?

In this post, I'll answer these questions for you. I'll help you understand excessive data exposure with examples and how you can prevent it in your React application.

What Is Excessive Data Exposure?

Excessive data exposure is a security vulnerability that occurs when your front end requests more data than desired. In web applications, anyone can open the browser developer tools and inspect incoming and outgoing HTTP requests. They can see the data payload received from these requests.

Thus, even if the front end doesn't necessarily use or consume this data, an attacker can still look at that data via the API call. In cases where an API sends more data that may be sensitive in nature than the front end requires, an attacker can use this data to cause damage to the users.

This is known as excessive data exposure.

In excessive data exposure, there is literally more sensitive data being exposed than anyone has access to.

Now let's understand this further with the help of an example.

Example of Excessive Data Exposure

Imagine you have an e-commerce store. You also have a large number of users and potential shoppers who regularly check out items from your store. Let's say that in order to finalize a purchase, your users have to check their credit card details as well as their order details. On the "Confirm Orders" page, you allow users to review what they want to purchase.

Then, on the "Checkout" page, you prompt them to check their credit card details. However, there is a single REST API endpoint for this page. This endpoint brings the items in your cart as well as your credit card details. Here's what the user flow might look like:

Now imagine if you as a user could share your cart items with a friend. That would generate a shareable URL for your "Confirm Orders" page where an authenticated user can only view data but not modify it. Sounds cool. But as soon as this page loads, you're hitting an API endpoint that also retrieves that user's credit card details. An attacker might steal this information to cause potential damage to this user.

How to Prevent Excessive Data Exposure

The most straightforward approach to preventing excessive data exposure is to refactor your REST API endpoints. If you know that your web service is sending out sensitive data that the front end doesn't need, you need to filter that data in your back-end query itself. This will essentially serve two purposes: preventing unwanted sensitive data from being exposed by the API and optimizing your database query.

However, the first solution is purely server-side. What if you're using a third-party web service over which you don't have much control? How will you prevent excessive data exposure from a front-end-based approach?

Instead of using REST APIs, you can use GraphQL-based APIs. GraphQL is an API architecture that gives the front end full control over what data it wants. Thus, now you can use this approach to request only non-sensitive data on the front. Let's see how we can use GraphQL to prevent over-fetching in a React application.

Set Up a React App

As a first step, we'll go ahead and create a new React application by running the following:

npx create-react-app react-excessive-data-exposure-app

That should create a brand new and fresh React project for us. Next, go ahead and edit the contents of the App.js file as shown below:

Now let's run the React app locally. To do so, you'll need to run the following command inside the root directory:

npm start

Then if you visit "http://localhost:3000", you should see the following page:

Using Public GraphQL API

To demonstrate how we can use GraphQL to overcome excessive data exposure, we need a GraphQL server or API first. To keep things simple, we won't go out and create our own GraphQL API or server from scratch. Rather, we'll use a dummy mock GraphQL API online to get things rolling quickly. We can then communicate with this GraphQL API from the React app we created in the previous section to understand how we can prevent the over-fetching of data on the front end.

For this purpose, we'll use GraphQLZero, a free fake online GraphQL API. Let's understand the use case and example on this API. We can visually test out the API, request, and response structure via the GraphQL playground using this tool. On the left-hand side, you'll find an editable section. This is where we can write our GraphQL queries.

Add the following query to this section:

query { user(id: 1) { id username email address { geo { lat lng } } } }

Then click on the big Play button in the middle. That should display a JSON response in the right section:

Great! Now we'll communicate to this GraphQL API via our React app. So let's do that.

Excessive Data Exposure in React

Inside App.js, we'll first import the useState hook from React so we can store the data obtained from an API call. We'll also import the useEffect hook so we can use the componentDidMount life cycle equivalent's in hooks to make an API call as soon as the page loads.

import {useEffect, useState} from 'react';

Next, we'll make use of the useState hook to create a state variable to store the API's data:

const [userData,setUserData]=useState();

After that, we'll create a local variable inside our App component to hold our GraphQL API's query. It's a simple string that holds the exact query we tested previously, as shown:

const QUERY=`{ user(id: 1) { id username email address { geo { lat lng } } } }`

After that, we'll create a useEffect, and inside the callback function, write the code to create a GraphQL API request to our mock server using JavaScript's Fetch API. Here's what that looks like:

Since we have to pass the QUERY object, each GraphQL API is a POST request, which is why the method is POST in the above code. Then, in the body part of the request, we send the query for the API call in JSON string. Finally, we tackle two .then callbacks to convert the response to JSON and consequently store it inside our state variable.

Next, we'll display this data in our App.js file:

Note that we're only interested in the username, ID, and email. So we extract those data from the API and then render them on the DOM. Once you do that, here's what your React app should look like:

That's cool. But let's inspect the API call inside the browser's network tab.

If you notice, we're only using some information like email, username, and ID, but we also get the user's address back in the response. Clearly, we're overreaching data on the front end.

If this data is exposed to an attacker, it can lead to excessive data exposure. So how can we prevent it?

Prevent Excessive Data Exposure in React

If we were working with a REST API, it would have been impossible to get around this via a pure front-end solution. Especially in this case, since we're using a third-party API, we have no control over how the API is structured, what data it sends, etc. Luckily, we're working with a GraphQL API where the front end can control what data it wants from the request.

Hence, all we need to do is update our query. Here's what the updated query looks like:

const QUERY=`{ user(id: 1) { id username email } }`

Now let's see what data we get back from the API:

Now we only get the user ID, username, and email back. Awesome! We have prevented unwanted and potentially sensitive information from being exposed on the front end.

Conclusion

I hope I was able to help you understand what excessive data exposure is and how you can prevent it in your React application. If you're working with a REST-based back-end architecture, a correct way to tackle this would be to refactor the backend API so that it returns only the required data. Until next time!

Rust Broken Authentication Guide: Examples and Prevention

StackHawk

Rust is a fast and reliable language that supports asynchronous, and it is quickly becoming the premier choice for performance-focused network and web applications. Authentication is the process of verifying the identity of a user, and it's an integral part of software development. For example, people trying to get access to the system must prove that they're legitimate users. This way, unauthorized users won't get access to the system.

For a language with high performance like Rust, what happens when authentication is broken? This means that cybercriminals can impersonate a legitimate user to cause havoc to the system. When this happens, the system is vulnerable to attacks. In this article, we will explore broken authentication, the different types, and how to avoid them in Rust applications.

What Is Authentication?

Authentication recognizes and verifies the identity of a user, and it happens at the start of the application. The user provides their credentials, which the system can compare with what's in the database. For example, the credentials are usually a match of the user's username and password. If the credentials don't match that of the database, the user won't get access to the system. This is because the system will consider them an illegitimate user.

While there are different means of authentication for different systems, users must provide a means of identification. For example, the credential must not be a password or an email address. User authentication is in three categories: The system will authenticate the user according to who they are, what they know, and what they have.

What Is Broken Authentication?

Applications are prone to vulnerabilities that can cause a security breach. Broken authentication is one such vulnerability.

According to OWASP (Open Web Application Security Project), broken authentication is the second on the list of critical vulnerabilities.

Broken authentication consists of vulnerabilities that cybercriminals can exploit to impersonate legitimate users. Sometimes, these vulnerabilities can be a result of developer error or from APIs (application programming interfaces) in the application. For example, if the application uses an API with a security breach, it could inherit them. Also, if an application uses a library that's vulnerable to authentication, it can cause a security breach.

Broken Authentication Types

There are different types of broken authentication vulnerabilities. In this section, we'll explore the different ways authentication can be porous and cause a vulnerability.

Predictable Login Credentials

Sometimes, users choose credentials that are easily predictable. For instance, passwords like "Admin" or "Password1" can be easily predictable for cybercriminals. A downside to this is that attackers can easily get hold of the user's account.

For example, criminals can apply brute force attacks until they can get access to the account of the user. A brute force attack isn't the only way attackers can get into a user's account. If the user permits a weak credential recovery process, the attacker can intercept the credential.

Sensitive Data Exposure

While software development firms try as much as possible to protect user data, sensitive data is vulnerable to exposure in many ways. For example, user login information can get exposed before they get to the database. Also, during password recovery when users forget their credentials, they could get exposed.

Sometimes, encryption doesn't protect user data from exposure. This is because attackers can decrypt data that has been poorly encrypted. For instance, research shows a vulnerability in version 1.0 that can allow attackers to decrypt data passing between a web server and the user.

Session Hijacking

Session hijacking is a term that describes when an attacker successfully takes over a legitimate user's account. With this move, the system thinks the attacker is the legitimate user and they get access to all user information.

Session hijacking happens when attackers compromise session tokens. These session tokens are unique strings of data that only the server and browser know about. This is for network communication, where the server trusts a session token from a browser and allows the user access. In session hijacking, the attacker can take over the user's session after the legitimate user has logged in. Session hijacking is different from session fixation. The former hijacks a user session after the user logs in, while the latter launches an attack before the user logs in.

Rainbow Attacks

Rainbow attacks are a series of attacks that target an application's database. When attackers target the database, they can get user credentials and let themselves into the user's account. A rainbow table is a table of reversed hashes that attackers can use to collect password hashes and decode them.

Session ID Vulnerability

Session ID vulnerabilities exploit the fact that some systems allow attackers to get a valid session ID and then manipulate users to authenticate themselves with the session ID.

How to Avoid Broken Authentication in Rust

We've explored the different broken authentication types in Rust applications. In this section, we'll discuss how to avoid them.

Encrypt Password and Add Salt to Hashes

Credential encryption can go a long way in protecting user data from exposure. For instance, if an attacker gets hold of a user's credentials, they'll have to decrypt it to a human-readable string. In Rust, developers can use libraries like rust-fnv to hash user credentials. Here's an example of how to use this Rust library in a hashtable or HashSet:

What this does is use the FnvHashMap and FnvHashSetwhich to store a hash of credentials in a HashMap or HashSet. Sometimes, firms only want to hash the user's password. For this, they can use Rust's bcrypt library. An advantage of using this library is the addition of salt to hashes. Here's how to use the bcrypt library:

extern crate bcrypt;

use bcrypt::{DEFAULT_COST, hash, verify};

let hashed = hash("hunter2", DEFAULT_COST)?; let valid = verify("hunter2", &hashed)?;

Use Passwordless Authentication and Session Invalidation

To avoid credential exposure, many firms are using passwordless authentication. In Rust, users can incorporate this with the Auth0 passwordless feature. This feature allows you to authenticate a user by sending a magic link or code to them. This magic link/code can be sent to the user's email address or phone number.

However, what happens when attackers launch a series of attacks to hijack the user's session? This is where session invalidation comes in.

Session invalidation clears authentication objects and marks them as invalid.

For example, when an attacker tries to use the account, they'll be logged out because the session is invalid. To do this, developers can incorporate either of the methods below:

HttpSession.invalidate()

session.inValidate()

Session Time-Outs

Developers can stop session hijacking, session fixation, and other attacks that can result from vulnerable session IDs by incorporating session time-outs. A session time-out is the time window when the user is inactive. When a user logs in to their account and stays inactive for a long time, attackers can steal user credentials or even hijack their session. What session time-outs do is lay out a time where the user will be logged out if they remain inactive.

In Rust, most libraries have the time-out traits for their sessions. For instance, in Rust's yubihsm crate, developers can use the time-out struct in the session module. This allows them to create a new time-out by setting the duration of the time-out.

Conclusion

Rust is an amazing language when it comes to security. For example, the compiler gives out errors like type errors when the developer makes a wrong choice. However, what happens when there's no compile-time error but users are making an error that'll cause a security vulnerability? This is where monitoring tools like StackHawk come into play. For instance, they can capture unsafe code that might lead to broken authentication. With StackHawk, you can also test APIs and third-party libraries in your application for security.

This post was written by Ukpai Ugochi. Ukpai is a full-stack JavaScript developer (MEVN), and she contributes to FOSS in her free time. She loves to share knowledge about her transition from marine engineering to software development to encourage people who love software development and don't know where to begin.

StackHawk March Newsletter 2022

Rebecca Warren

The Changelog: New Features to Kaakaww About

Auth Wizard.

We know getting authentication properly configured is no easy task. But now, you can quickly get an updated YAML that is customized to your auth scenario in the StackHawk UI.

Defect Dojo Integration.

For teams that track vulnerabilities in Defect Dojo, you can now send StackHawk findings with our integration. And, updates to scan results can auto-close findings in Defect Dojo. Check out the docs

[ICYMI] Log4Shell Beta.

A couple of lines of YAML added to your StackHawk config is all it takes to see if your application has a discoverable and exploitable Log4Shell vulnerability. Drop us a line to join the beta or read the docs for more information.

⚡️ ZAPCon 2022 Replay

This month, StackHawk hosted ZAPCon 2022, a free virtual conference dedicated to helping users level up their ZAP and AppSec skills.

If you missed the chance to attend ZAPCon, don’t worry. The ZAPCon 2022 Replay is now available on StackHawk’s YouTube channel. You can watch all the talks from security experts, follow along to hands-on workshops, and catch exclusive announcements about ZAP project updates.

Watch the Replay

Introducing The ZAP Fund

At ZAPCon, StackHawk CEO Joni Klippert announced the ZAP Fund, a $100,000 fund dedicated to supporting the ZAP and the project’s community.

A portion of the fund is allotted to resolving open ZAP issues through a bounty program. If you want to participate in the bounty program, visit the website below to learn more. 👇

The ZAP Fund

Other Happenings: Because We Have to Keep Corporate Busy Somehow

📺 Hawk Talks

📖Reading Material

📽 Virtual Events

April 6-7: APIsecure
April 12: CTO Summit: Shifting security left with DevSecOps
April 21: The Austin 2022 CTO Summit
April 25: AppSec Panel on Security Boulevard

💼Jobs @ StackHawk

Developer Advocate
Solutions Architect

❤️ Give Us Some Love

Share the goodness of developer-centric application security. We are always grateful for recommendations and referrals! We’d love for you to share StackHawk with your friends and colleagues, or leave us a review on g2.

StackHawk April Newsletter 2022

Rebecca Warren

The Changelog: New Features to KaaKaww About

Our New Snyk Code Integration is Live! With StackHawk’s new Snyk integration, teams can correlate security issues between dynamic security testing (DAST) and static security testing (SAST) to find and fix the most important application and API vulnerabilities.

Use this integration to focus your team on the issues that are most critical to fix and to remediate those issues on the fly.

📖 Check out the Docs

👀 Watch a Snyk Peek

🦅🐶 StackHawk and Snyk in Action

Join us on Wednesday, May 4, at 10 AM PST to watch StackHawk's Chief Security Officer Scott Gerlach and Snyk's Tomas Gonzalez demonstrate how the Snyk Code integration can help you find and fix security issues quickly. Follow along to see how your team can streamline security testing in CI/CD using these tools.

Save Your Spot!

Other Happenings: Because We Have to Keep Corporate Busy Somehow

📺 Hawk Talks

📖Reading Material

📽 Virtual Events

May 10: DockerCon 2022

🎟 In-Person Events

May 16-20: KubeCon EU 2022
May 12: Chicago CTO Summit
May 18-19: GlueCon 2022
May 19: New York CTO Summit
June 4-5: BSidesSF 2022
June 6-9: RSA Conference

💼Jobs @ StackHawk

Technical UX Writer
Junior Solutions Architect
Senior Solutions Architect

❤️ Give Us Some Love

Vue Broken Authentication Guide: Examples and Prevention

StackHawk

In this article, we'll discuss broken authentication in Vue and how to address it effectively in your projects.

We'll start by defining what broken authentication is. Then we'll explore the two common methods that facilitate broken authentication vulnerabilities. Next, we'll show you some examples of the most common broken authentication vulnerabilities on the web. Finally, we'll offer effective mitigation practices.

By the end of this article, you can expect to understand the fundamentals of authentication, how broken authentication affects your security, and what you can do about it.

We wrote this article for developers with experience in Vue and JavaScript. However, if this is not your development stack of choice, we encourage you to find an article with your technology of choice on our blog.

Defining Broken Authentication

To explain what broken authentication is, let's briefly revisit the definition shared in a related article. As previously stated, "The term broken authentication is an umbrella used for several vulnerabilities that attackers can exploit to hijack our systems and impersonate other users."

Authentication is the mechanism in your platform that ensures that only a verified user can access the information and privileges provided on a web application.

We refer to authentication as broken when a bad actor successfully circumvents the procedure, whether by impersonating a user or acquiring privileges.

Going back to the referenced article: "To be more specific, broken authentication refers to the vulnerabilities or weaknesses inherent in an online platform or application's authentication mechanisms. We can usually find these vulnerabilities in poor session management and credential management." Both of these avenues could lead to broken authentication since bad actors can impersonate users, either by hijacking the session ID or stealing the login credentials of other users.

Furthermore, this breach allows bad actors to compromise passwords, session tokens, user information, and other elements to take over user identities.

Broken Authentication Methods

Now that you know that broken authentication attacks target credential and session management mechanisms, let's see how bad actors can seize these systems.

Deficient Credential Management

If your system incorrectly implements credential management, a bad actor can hijack your authentication mechanism and gain access to the system. One of the ways this happens is when you allow weak passwords.

When your system allows users to use passwords like '12345' or 'password,' a bad actor can make use of tools and techniques like brute force, rainbow tables, and dictionaries to crack them.

The second way bad actors can take over your security is by exploiting weak cryptography. Inadequate encryption mechanisms like base64 and hashing algorithms like SHA1 or MD5 puts user credentials in a vulnerable spot in the case of a security breach.

Inadequate Session Management

As stated by the OWASP, the typical interaction flow between a server and client starts with issuing a session ID and registering the interaction. This session ID is analogous to login credentials. Therefore, if a bad actor successfully steals this session ID, he can impersonate the victim. This is known as a session hijacking breach, and it's common on the web.

Broken Authentication Vulnerabilities

There are many ways to take advantage of poor implementation of session and credential management systems. Here are a few of them.

Password Spraying

Password spraying exploits accounts that use simple and weak passwords such as '12345' and 'password,' rainbow tables, and password dictionaries.

Credential Stuffing

Credential stuffing takes advantage of credentials obtained from previous breaches from other platforms. This approach presumes that many users reuse credentials due to laziness or friction between platforms.

Session Hijacking

When you expose the user session IDs, you make your users susceptible to hijacks by bad actors. One example is when a user forgets to log off before leaving and a bad actor hijacks the session to act like the victim. Furthermore, when your system issues the same session ID before and after authentication, it could open the door to a session fixation attack.

Session ID URL

Following the previous point, if you implement session ID by adding it to the URL as a query string, any individual gaining access to that URL can impersonate the victim. Bad actors can achieve this by hijacking insecure Wi-Fi connections, man-in-the-middle attacks, or simply looking at the victim's address bar.

Phishing Attacks

By sending emails disguised as legitimate, bad actors can make victims click on links to websites that appear legitimate, persuading them to disclose their credentials.

Fixing Broken Authentication

The best way to mitigate these vulnerabilities requires following the best practices laid out by the OWASP. However, this can be a complicated and tricky process that can unintentionally break some things.

The good news is that you can address most of the issues by integrating robust, third-party solutions like Auth0. Their platform will protect your users' credentials and provide you with the best tools to secure your application.

Let's briefly see how to implement it.

Integrating Third-Party Authentication

The first thing you need to do is create an account on the Auth0 website. Once you've done that, create your application and get the keys necessary to integrate the library here.

All you need to do is provide the callback and logout URLs, which should point to your application. Once you do that, make sure to specify your domain in the Allowed Web Origins.

Finally, save the ClientID and Secret provided by the application in a safe place. These will be the credentials with which your application will communicate and interact with Auth0.

Now, proceed to your application console and type the following command:

npm install @auth0/auth0-vue

Then in your main app class file, add the following code, replacing the placeholders with your credentials.

Finally, add the proper login code to make use of the Auth0 library. As stated in the official Auth0 documentation for Vue: "To add a login to your application, use the 'loginWithRedirect' function that is exposed on the return value of 'useAuth0', which you can access in your component's setup function."

This code is a simple example of making use of the login feature. You can use it as the basis of your specific implementation that satisfies your needs.

Please check the official documentation if you want to learn more about integrating Auth0 into Vue.

Beyond this, make sure to follow the best practices and guidelines to minimize the potential for exploitation. Among the most critical steps are the following:

Secure password storage

It is essential that you encrypt, hash, and salt all passwords in the database. This ensures that users' credentials are safeguarded in case of a breach.

Thankfully, Auth0 takes care of this for you.

Don't allow weak passwords

Weak passwords must be heavily discouraged and, if possible, prevented. In addition, users must be required to meet specific requirements when creating their passwords, like password length and the inclusion of special characters.

You can do a lot of this on the front end by specifying restrictions on the user forms. However, if your users use external authentication providers like Google or Facebook, they have their own password policies.

Add a strict credential recovery process

We recommend that you implement a mechanism for credential recovery. This should require some verification steps that make it cumbersome for bad actors to abuse.

Control session length

The best course of action against session shenanigans is to end the user sessions after a period of inactivity.

You can change this in the Auth0 dashboard by going to Settings, then Advanced, and then scrolling to the login session management segment. More info here.

Improve session management

Your platform must provide unique session IDs after every authentication process. Additionally, you must invalidate old session IDs as soon as a session ends.

Disregard session ID URL

The information on web URLs must be protected with SSL and must not include session data.

Phishing

The best defense against phishing is teaching your users to identify and disregard phishing attempts. Additionally, share your communication policies so they know what to expect from you.

Conclusion

Finally, a lot more can be done to reduce attacks from bad actors. Of course, there's always somewhere else to put effort, from implementing sophisticated biometric or two-factor authentication mechanisms to running regular penetration tests to strengthen your system.

In this case, we recommend you consider our solution at StackHawk. Our dynamic application security testing (DAST) solution for your team is a great and robust solution that will empower your team's capacity to protect your assets and clients.

Check it out here.

This post was written by Juan Reyes. Juan is an engineer by profession and a dreamer by heart who crossed the seas to reach Japan following the promise of opportunity and challenge. While trying to find himself and build a meaningful life in the east, Juan borrows wisdom from his experiences as an entrepreneur, artist, hustler, father figure, husband, and friend to start writing about passion, meaning, self-development, leadership, relationships, and mental health. His many years of struggle and self-discovery have inspired him and drive to embark on a journey for wisdom.

What is Command Injection

StackHawk

In software development, security is paramount, but developers tend to forget to test their applications for vulnerabilities. One such vulnerability is command injection. This blog post aims to help developers, testers, and users understand, detect, and avoid command injection vulnerabilities in their applications.

What Is Command Injection?

Command injection is a cyber attack wherein an attacker takes control of the host operating system by injecting code into a vulnerable application through a command. This code is executed regardless of any security mechanism and can be used to steal data, crash systems, damage databases, and even install malware that can be used later.

Attackers can access a target system through command injection by using various methods and techniques. The attacker runs arbitrary commands in the system shell of the web server that can compromise all relevant data.

Next let's look at how it differs from another widespread attack: code injection.

How Is Command Injection Different from Code Injection?

Code injection is an attack that includes the injection of code executed by an application. This usually involves the attacker sending the target application a request (often through a browser) that includes the injection code. A lack of sufficient input/output data validation allows it to happen.

A command injection occurs when an attacker alters the application's default function for executing system commands.

No new code is added. Command injection can lead to various breaches, such as downloading tools, stealing and changing credentials, or deleting files that depend on the privileges.

Vulnerabilities That Can Lead to Command Injection

Command injection occurs when an application's vulnerability allows an attacker to extend the application's default functionality by executing system commands. However, executing commands through the application's code is also possible. This is also called code execution. In this case, the goal is to run arbitrary commands through it.

Now let's look at some of the flaws that might lead to command execution via command injection or code execution.

1. Arbitrary Command Injection

Arbitrary command injection occurs when an application is vulnerable to a malicious command entered by a user that has the potential to execute any command directly on the underlying host. The attacker may be able to gain access to sensitive data using this type of attack.

2. Arbitrary File Uploads

When users are allowed to upload files with arbitrary file extensions, command injection can occur when these files are stored in the web root.

3. Server-Side Template Injection

Server-side template injection is possible when web applications employ server-side templating technologies like Jinja2 or Twig to produce dynamic HTML responses. When user input is integrated with a template in an unsafe manner, SSTI vulnerabilities exist, resulting in remote code execution on the server.

4. Insecure Serialization

Other vulnerabilities, such as improper deserialization, can be used to execute arbitrary commands in addition to the conventional command injection vulnerabilities. This is because the server-side code deserializes the user-supplied serialized material without verifying it.

Although this is often called the insecure serialization class of vulnerabilities, if the target program fits specific conditions, such as having proper gadgets in the classpath, it eventually leads to command injection.

Understanding Command Injection with an Example

In the code below, we use a direct OS command “touch” to make changes to the file, which is not secure. A hacker can exploit this.

The best way to prevent command injection is to use parameterized functions like write() that enforce the separation between the arguments instead of eval, process, etc. Safe APIs are not used in the above code.

Developers should use safe APIs for reading and writing files here instead of eval(), touch, or any other type of direct OS commands and evaluation. And if there are no safe APIs available, sanitize all inputs and remove characters that may be interpreted, such as ‘;’, etc.

Here is how you can prevent command injection using JavaScript.

We use open sync and close sync instead of a direct OS command, touch.

Types of Command Injection

Command Injection is of two types. One can be predicted by directly looking at the response, and the other can't. Let's take a broader look at the two command injection types with examples.

1. Result-Based Command Injection

In result-based command injection, the result shows the command's output directly, which means the user can directly see the outcome of the arbitrary command that he wrote in the response.

This input does not have any validation and can lead to command injection.

This form has an input and a button that can create a file. As you can see, we already have some files in the folder printed in the image.

Let's check whether it has command injection or not by entering an OS command a; ls; in the input. This would not show any effect in the response but would also not throw an error. And now we know that it allows a semicolon.

So let's try X; rm -r *. This command removed all the files and broke its functionality. We can now see the result directly in the response, which shows us that this application is vulnerable to result-based command injection.

2. Blind Command Injection

In blind command injection, the response does not show the command's output. The user cannot predict whether there is a command injection or not just by seeing the response.

There are two techniques to find out if the application is vulnerable to blind command injection or not.

2.1 The Time-Based Technique (Blind)

From the delay in the execution time, one can detect this kind of security risk. The ping command for time delay allows you to select the amount of ICMP packets to send and the time it takes to perform the command: 127.0.0.1 ping -c 10. The program will ping its loopback network adapter for ten seconds due to this instruction. Once validated, we may export the output of the injected command char by char using a series of OS commands like cut, head, etc.

We can use a time-based technique to check whether there is command injection. In the instance of result-based command injection, you can use this technique to check if there is a command injection or not since we could not see it directly in the response the first time. If you enter test1; ping -i 1 -c 15 127.0.0.1, you will notice a delay in the output execution.

2.2 File-Based Technique (Semi-Blind)

File-based command injection happens when you can write the command in the file that is accessible to us when we cannot directly see the output in the response. An attacker could use this the same way. The difference will be that this time he will be entering the command in the file that we will have access to instead of an input.

How to Prevent Command Injection Vulnerabilities

The problem with command injection is straightforward: if your code makes a call to an operating system command in the same manner that a user would type it, you are putting the server at risk.

The most effective way to prevent OS command injection vulnerabilities is by never running OS commands from the application.

Suppose your web application must call OS commands. You should use a framework or module such as the fs module in JavaScript that prevents OS command injection attacks. You can do this by automatically escaping or encoding user-submitted data or preventing user-submitted data from being executed as a command.

There are several advantages to this approach. First, it simplifies and strengthens the application's design and its architecture. In particular, it allows developers to think about the application in terms of higher-level tasks rather than lower-level commands. Second, it reduces the possibility of introducing vulnerabilities such as command injection.

Best Practices to Avoid Security Vulnerabilities

Thousands of security vulnerabilities are discovered every year in all kinds of applications. We put together a list of best practices to avoid them.

1. Use Strongly Validated User Inputs

No matter the data source or data type, and regardless of the programming language, input validation is vital. You can implement this by whitelisting strings or characters. You can use regex to allow only specific characters like alphanumeric and restrict others.

No matter what programming language you use or how big your codebase is, this practice will always protect you.

2. Use the Principle of Least Privilege

The principle of least privilege (PoLP) restricts an individual's privileges to the rights required to perform their duties. The objective is to reduce the likelihood and severity of successful assaults.

3. Keep Public and Private Data Separate

Another important tip for securing private data is to keep the public and private data separate. This can help keep the private data safe even if the attacker gets access to public data. He will get only the public data.

4. Automate Testing for Command Injection in the Build Pipeline

In the era of cyberattacks and data breaches, organizations increasingly focus their attention on data security. Automation is one of the best ways to tackle the growing volume of vulnerabilities and ensure that data is secure. A dynamic application security testing (DAST) solution can scan for and identify vulnerabilities regularly and automatically. This is where StackHawk is invaluable.

StackHawk's DAST solution provides unique features like automated preproduction scans, microservices scans, API scans, and many other valuable features to secure your application before it goes to production.

Conclusion

You can learn even more about command injection vulnerability on our blog. And as a reminder to our readers, we're always here to help you with any security-related problems you might be facing. So if you have any questions about this or any other security-related topic, don’t hesitate to contact us.

Guide to Security in Django

StackHawk

The software world is moving to the web. Businesses, services, and products are all moving to web applications due to the reach and accessibility of web apps. With this major migration, web application frameworks have improved and become more powerful than ever. But there’s a challenge: security. With a majority of businesses conducting transactions online, web applications became a valuable asset, and also became a valuable target for malicious actors. Hence, security became more crucial than ever.

One of the top web application frameworks and a favorite of developers is Django. Django is a Python-based open-source web framework that allows rapid development. And along with scalability, a strong community and a batteries-included framework (loaded with most of the features required for development), Django also focuses on security. In this post, we'll look at some security features and libraries that come built into Django. Then we’ll see how its security features protect against common web attacks. And finally, we’ll go over some best practices for your Django projects

Django Security Features

Escaping Dangerous Characters

Django has some built-in features that handle user-submitted data to make it safe for an application. These features escape possible dangerous characters in requests, making the data safe for the application to use.

The first rule of web application security is to never trust user-submitted data. Of course, the majority of the data you receive from the user side will be legit and safe. But an attacker can also maliciously craft data to damage your application or system. For example, if your application uses a SQL database and executes queries based on user input, a malicious actor can craft input that executes a query it's not supposed to. And malicious data from the user side means more than data entered in user input fields, like in forms. An attacker can also manipulate web requests, and Django’s got that covered too.

Clickjacking Protection

Clickjacking is a technique in which a malicious actor tricks a user into clicking on something other than what the user intends to. So how does this happen? One of the common ways is by placing a malicious web element or page in a legit web page using iframe. For example, when a user tries to click on a button, they'd end up clicking on a malicious button on a different page altogether.

Django provides clickjacking protection in the form of X-Frame-Options middleware. This feature prevents a different site from rendering inside a frame.

Enforcing SSL/HTTPS

Encryption is important to keep data secure. Django has encryption features that help you enforce secure connections. Some of these features are:

Redirect HTTP requests over HTTPS
Send cookies only over HTTPS connection
HTTP Strict Transport Security (HSTS)

These are some of the main security features for Django applications. Although these cover the basics, you'd need more security practices as per your use case. So along with the default security features, you can bring in security libraries to make your security better.

Security Libraries for Django

Django is based on Python, and Python is very well known for its huge collection of libraries that meet almost every need. It has many libraries to improve the security of your Django applications. Here's a brief list of some security libraries for Django:

Secure Auth: Provides secure authentication (multi-factor authentication, or MFA) with a time-based one-time password (TOTP), short message service (SMS), security codes and question–answer pairs. You can further improve login authentication with IP ranges and captcha.
Django Defender: Blocks brute-force login attempts.
Django Session Activity: Helps identify suspicious and malicious behavior by listing recent account activity and sign-outs from all sessions opened on computers.
Restricted Sessions: Restricts Django sessions to the IP address and/or user agents it authenticates. So if the IP or user agent changes after creating the session, the request receives a 400 response, and the session gets flushed.
Django Rules: Provides object-level permissions for Django.
Admin Honeypot and Django Honeypot: Help create decoys to identify malicious activity.
Django Cryptography: Encrypts data.

Now let's look into some of the most common attacks and how Django security features protect against them.

Common Django Security Attacks

Common attacks on Django applications are mostly the same as the common attacks on any web app framework, because the tools and general processes for particular attacks are the same for all frameworks.

Although you might find attacks specific to Django, these are relatively few. Now, let's go through different attacks and see how Django fights against them.

SQL Injection

SQL injection is when an attacker injects crafted SQL queries into a request. The attacker attempts to make the application execute a query that it ideally would not. Two main criteria for a SQL injection to work are

the application uses a SQL database, and
user-submitted data is part of the SQL query.

The main source of threat for a SQL injection is user-submitted data that the underlying SQL query uses as a parameter. Django SQL injection protection uses query parameterization. You can divide a complete SQL query into SQL code and query parameters. The application carefully escapes any data it uses as a parameter to make it safe.

Cross-site Scripting (XSS)

An XSS attack is a technique wherein a malicious actor injects crafted malicious client-side scripts into an application to manipulate the application's functions. The origin of an XSS attack is an untrusted source of data. Django XSS protection uses the concept of templates to prevent XSS attacks. By default, Django templates escape special HTML characters in the HTML code to prevent XSS attacks. For example:

< is converted to <
> is converted to >
‘ (single curly quote) is converted to ' (single straight quote)
“ (double curly quote) is converted to " (double straight quote)
& is converted to &amp

So even when an attacker injects a client-side script, the browser doesn't process it as code. Although this provides a basic level of security, it's not foolproof. You need to take extra measures to make your application more secure.

Cross-site Request Forgery (CSRF)

CSRF is an attack in which an attacker uses the authentication information of a user to trick the authenticated user into performing an action that they don't intend to perform. Django CSRF provides protection against CSRF using its CSRF middleware and creating a secret value, a.k.a CSRF token. A CSRF token is a unique, secret value that is sent to the client-side from the server. And for every subsequent request from the client, the server checks this secret value. This prevents a malicious user from replaying a form POST to your application. For a malicious actor to execute a CSRF attack, they'd have to know the secret value specific to each user.

Open Redirect

An open redirect is a security weakness in an application that occurs when the application uses user-controlled data for redirection. If you don’t check that the user-controlled data is secure, then an attacker can manipulate the data and execute an open redirect attack. Django open redirection protection allows you to run the URL through a safety checker. The is_safe_url() function from django.utils takes a URL as input and checks if it’s safe or not, and blocks the redirection if it finds something unsafe.

Path Traversal

A path traversal attack is when an attacker manipulates a URL or a request to access directories stored outside the permitted directory of the application. This technique mostly relies on the directory structure and a directory reference. For example, if the current directory is /django, an attacker could access the parent directory using ../ (double dots are used to refer to parent directory).

The latest versions of Django provide protection from path traversal attacks by enforcing use of absolute paths. Django uses Python’s os.path.abspath to determine if the absolute path is located in the permitted directory. Or you can use Python's os.path.relpath module to determine the path and compare it with the permitted path.

More Security

As you can see, Django is very security-focused. But is it enough? Absolutely not! When it comes to security, no amount is enough. So along with the built-in features of Django and its security libraries, here are some security best practices to follow.

Use additional encryption. Although Django by default provides encryption features for data flowing over the network, you need to take care of encryption in other parts of the application. For example, you need to encrypt the secret keys that you're using in your application. This is especially useful if you're using version control systems.
Change default URLs to custom URLs. For example, if the default to access an admin page is /admin then change it to something like /my-app-admin-page. This will make it difficult for attackers to find special portals.
Use MFA.
Be careful with Git commit. Make sure not to commit any sensitive data.
Use honeypots to understand what attackers are targeting and what techniques they’re using. Then put extra focus on improving security based on the data.
Continuously test your application for security weaknesses.

Summing It Up

Django is one of the most convenient web application frameworks. You cannot compromise on security in today’s applications. Along with making development easy, Django focuses on security and provides multiple security features by default, and for some other security features, you have to either enable them or configure them. We've explained different security features of Django, additional libraries that can enhance security, and best practices for security. They apply to all applications in general, but they’re not enough.

Security is best when it's above the benchmark and custom-tailored for your application. Therefore, once you implement all the basic security practices and fix common weaknesses, you need to focus on application-specific security. This calls for regular monitoring, keeping up-to-date with the latest security weaknesses and fixes, and most importantly security testing.

Kotlin Broken Authentication Guide: Examples and Prevention

StackHawk

So, you've created a form that works. Did you take the time to consider if it leaves your user open to attacks?

As developers, we're often more concerned with making sure our code works, is maintainable, and is easy to read than fixing bugs. However, if we don't prioritize security, we leave our applications open to malicious intents. As such, it's crucial to make security part of our development process. But to do this, we first have to understand the types of threats our apps are open to.

In this post, I'll explain how to defend your Kotlin application against broken authentication. First, I'll explain a few common authentication vulnerabilities. Then, we'll look at solutions for making your Kotlin applications more secure. Most importantly, you'll see that protecting your users against nefarious attackers doesn't have to mean extra work!

What Is Broken Authentication?

Broken authentication is a broad term that encompasses several vulnerabilities. Our focus will be on two main weaknesses:

session management: the hijacking of a user's session IDs
credential management: the hijacking of an authentic user's credentials

Attacks can either be very specific and target an individual. It's also common for attackers to launch widespread attacks.

Session Management

To begin with, whenever a user interacts with an application, they're assigned a session ID to help identify them. This is a unique ID that the application uses to communicate with the user. Session IDs are commonly found in the form of shared preferences. Since shared preferences are a great way to keep users logged in, attackers will try using various methods to obtain these IDs, thereby obtaining protected information.

Let's take a look at some different types of session management attacks and how you can prevent them.

Attack: Session ID URL Rewriting

In session ID URL rewriting, a user's session ID appears in the URL. In this scenario, you've exposed your users' private data to widespread attacks. This can lead to attackers sniffing out and gaining access to the session ID.

Solution

Kotlin is still mostly used for developing mobile apps however it is possible to build web apps using Kotlin. It will be important to use HTTPS on that website. In short, HTTPS authenticates websites and protects information the user submits. Hackers are unable to decrypt user information, thus decreasing the likelihood of an attack.

The padlock symbol you see next to the URL of most websites represents HTTPS and lets your user know the website is secure. The Adobe business platform back end was migrated from Java to Kotlin. The lock icon assures users that the website is safe to use.

The lock icon next to the URL assures users a website is secure

Fortunately, Kotlin has many frameworks you can use to serve, consume, and test HTTPS. For example,Ktor and http4k are popular frameworks for connecting Kotlin applications. Comparatively, Ktor is fully asynchronous while http4k isn't. It's important to choose the framework that works best for your needs.

Attack: Session Fixation

Mobile apps connect to external services to authenticate a user. These include their host servers, other mobile resources, and third-party services. Hackers will use vulnerabilities within this communication to launch an attack.

In session fixation, the attacker tries to trick a user into authenticating a predetermined session ID. An attacker will try to predetermine a session ID. They then send a link with the predetermined session ID to the user. This will prompt the user to log in. Misled into believing the link leads to a legitimate application, they enter their credentials. Attackers are able to gain access to protected resources because they now have access to an authenticated session ID.

Solution

Mobile Client Certificates

The easiest way to block non-human attacks from gaining access to your app is through mobile client certificates. In essence, applications use mobile client certificates to authenticate themselves to the back end. The client certificate simply validates that the connection is coming from a trusted source and should be allowed access to the back end. As a result, this allows the firewall to block unauthorized apps or malicious bots. Most importantly, this allows only trusted apps to gain access to your back end. Think of it as a digital handshake between your application and the external service.

Fortunately, Kotlin has support for incorporating mobile client certificates within your app. There are three ways to add certificates using Kotlin: network security configuration, trust manager, and certificate pinning. Each has its own strengths and weaknesses, so make sure to pick the one that's best for your Kotlin app. The code below is an example of certificate pinning used together with okHttpClient.

Ending A Session

Additionally, ending the session length after a long period of inactivity and logging out after a certain period of time can reduce the chances of a breach. You can remove or add session IDs using shared preferences. Equally important, Kotlin will store the shared preferences within the device itself. So, remember to encrypt them so anyone who gains access cannot read them. Also, make sure to destroy the IDs once your user becomes inactive for a long period of time.

To illustrate, consider a movie streaming app like Amazon Prime. A streaming app is going to want to make it easy for its users to navigate through the app without logging in every time. Conversely, a banking app should log out users after a few minutes since the likelihood of an attack is much higher. With this in mind, be sure to clear the saved data when the user is no longer active or leaves the app. You can use the activity lifecycle, onDestroy and onResume, to do this.

Credential Management

The easiest way for attackers to gain access to protected information is by using a user's credentials.

Attackers will try to gain access to a user's credential pair (i.e., their username and password). Gaining access to these subsequently leads to an attacker having control of a user's account. This gives the attacker access to protected resources.

Attack: Credential Stuffing

Credential stuffing is on the rise instead of targeting large-scale corporations. Basically, this type of attack happens when an attacker already has access to user credentials.

Often, hackers will sell or give away credentials to other attackers. They have gained access to an unencrypted database. These attackers will automate trying different username and password pairs. In fact, hackers will do this using virtual environments such as emulators.

Above all, this is a numbers game. The intention is to hijack user accounts. Attackers do this because people often use the same password and username on different applications. In reality, there are billions of credentials currently that attackers have been able to gain access to.

Solution

For that reason, one of the best ways to significantly prevent your mobile app from falling victim to credential stuffing is to prevent it from being run on virtual devices. These include simulators, emulators, virtual environments, debugging tools, and other virtual environments. The code below simply checks to see if the app is opened in an emulator.

First, we gather all the emulators in the market. Second, Kotlin allows us to evaluate their properties, mainly their build value. Finally, we use the return value to determine if the application can be granted access.

Hackers want to use the servers and back end to gain access to the app. In this situation, remember to encrypt all API endpoints, as attackers will use this information for credential stuffing. For instance, it's advisable to encrypt usernames and passwords since attackers need this information for an attack. For added protection, consider using a keystore, which makes it more difficult to extract the encrypted data from the device.

Attack: Password Spraying

Password spraying, a brute force attack, is similar to credential stuffing. Spraying doesn't involve already existing passwords and username pairs. Attackers will try to guess user credentials using common phrases, terms, birthdays, etc. The assumption is many people will choose weak passwords. On average, users have to remember 100 passwords. This results in people using weak or reusing passwords to make their lives easier. Above all, this can lead to your app being vulnerable to malicious attacks and breaches.

Solution

In general, using passwordless authentication eliminates unsafe password behavior. Users often pick common passwords that are very easy to hack. These make it easy for hackers to exploit this vulnerability. Consider sending users verification links, requiring an SMS that verifies ownership, or using biometrics. Biometrics, in particular, is a great security feature as it requires a unique physical action from the user. And Kotlin supports using biometrics within your application.

Conclusion

Broken authentication can have serious ramifications for your Kotlin application. That's why it's important to make security a part of your development process.

As a developer, you need to understand the most basic types of vulnerabilities out there when coding in Kotlin.

This way, you can plan better and execute code that protects your users from malicious attacks. All things considered, implementing session and credential management shouldn't be an afterthought.

Fortunately, Kotlin comes with many frameworks and libraries we can use to mitigate these risks. Using a tool like StackHawk that will run tests and find all vulnerability issues before the application is pushed to production will save you in the end. As more businesses provide mobile applications for their users, this will make them an attractive target for attackers. It's important as developers to place protocols in place that will deter such attacks.

This post was written by Sinazo Bogicevic. Sinazo is a software developer with a passion for blockchain and mobile development. When she's not creating amazing products, she can be found either writing or talking about tech for the not so tech-savvy.

Vue XML External Entities (XXE) Guide: Examples and Prevention

StackHawk

In this article, we'll address the subject of Vue XML external entities injection. Our goal is to offer you a solid foundation to understand and mitigate XML external entity injection vulnerabilities in Vue and NodeJS. Additionally, we want to help you prepare to implement solutions in your projects.

It's important to note that we'll be providing mitigation strategies for NodeJS since the bulk of vulnerabilities lie in the back end of applications.

We'll first explain what XML is. Then, we'll give you some basic examples of XML external entity injection vulnerabilities and exploits. Finally, we'll provide you with strategies and mechanisms to prevent this exploit from affecting your application.

It goes without saying, but this article might not be for you if you don't have any experience with Vue. If you just want to know what XML external entity injections are, we recommend you go to our in-depth article about it here. Additionally, if you just want to learn about the basics of Vue, you might want to spend some time here.

Explaining XML

XML (extensible markup language) is a markup language for storing, transmitting, and reconstructing data. This language defines rules for encoding documents in both human-readable and machine-readable formats.

But wait—why does a markup language represent a threat to your systems?

The truth is that we make use of this language everywhere to process data in a convenient and human-readable way. Additionally, most XML processing tools in use allow for the specification of what is known as an external entity.

This entity, commonly a URI, is retrieved and processed during the parsing of the XML file. This prompts the parser to request and include the content inside the XML document. And, as you might've guessed, this is a window into trouble.

XML external entity injections, also known as XXE injections, are attacks that target XML parsing vulnerabilities. And, given that most systems that use XML parsing functionalities that face the user are potentially vulnerable, they can allow a bad actor to access files and resources on the server.

Given that a determined bad actor could use this entity as an avenue to retrieve any resource in the server, this vulnerability could be devastating for our security. All that's needed is a sufficient understanding of server structures and information about the technology stack in use.

Examples of XML External Entity Injection Vulnerabilities

The biggest threat offered by XXE injection is its simplicity.

Most developers won't be able to spot the dangerous code. Many won't even see danger at all, even when it's right in front of them.

So, to prevent that, let's see some common examples.

This XML document contains just one username element.

<?xml version="1.0" encoding="ISO-8859-1"?> <username>Michael</username> </xml>

Nothing scary here, right? Well, we haven't added any external entity yet.

OK, how do we add an external entity?

Simple. External entities are simple XML tags that use a system identifier within a DOCTYPE header.

This header works by adding more properties to the XML file structure itself. This would be, for example, a URL referencing another XML file containing additional data—nothing complex.

But what if we take advantage of this feature to retrieve something we shouldn't? For example, the following code containing an external XML entity fetches the content of /privates.txt and displays it.

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///privates.txt" >]> <username>&xxe;</username> </xml>

Yikes.

It's painfully clear that this is a potentially catastrophic vulnerability since these entities can access local or remote content within our server.

This is particularly awful if you make the mistake of keeping sensitive files on your server. Essentially, this would eventually provide a path to a hostile takeover of your whole platform.

Incidentally, XML external entity injection attacks can also access local resources that may return data in a loop, impacting application availability and leading to a kind of denial of service attack.

Now, if you're paying attention, this is when you should be freaking out and start advocating for disabling XML file processing altogether.

But don't be so hasty. There are still steps that we can take to mitigate this vulnerability.

Mitigating XML External Entity Injection Vulnerabilities

Now that you've calmed yourself a little bit, let's explore how to prevent your systems from falling victim to these attacks so you can keep your job.

First and foremost, mitigating XXE injection attacks is actually quite simple—sorry for the fearmongering.

Assuming that you need the functionality for loading user-provided XML files, as long as you're not deliberately attempting to open a back door for exploits, most libraries do a decent job protecting your application.

The general approach to prevent this exploit is not to use libraries that support entity replacement like LibXML. And, if you have to, disable the feature altogether.

Working on the Code

Now, this mainly concerns the back end of your application. In our case, this is NodeJS, but if you're parsing XML in the front end for any specific purpose, avoid using libraries that support entity replacement.

As we've mentioned in our NodeJS article about the subject, "Sadly, NodeJS does not have a built-in XML parsing engine, so, likely, you might already be using this library in your project. But no fret; entity replacement is disabled by default."

Nevertheless, we recommend that you explicitly disable this feature in your project.

You can do this by simply changing all initializations of the library like so.

const lib = libxmljs.parseXml(xml, {noent: true});

Luckily, the latest versions of LibXML make it tough to allow entity replacement on purpose. Nevertheless, we want you to know that regardless of your approach, you may still be vulnerable to a DoS attack when using LibXML in this way.

Now, if you absolutely have to have this feature, you can still minimize the potential for exploits by safe-listing the external entities you allow.

By simply checking the XML document before parsing it with our library for any strings containing any "ENTITY" not in our list, we can provide a minimum level of security to our application.

Surefire Solution

The last thing I want to leave you with is that the best approach to security is not to have a door open in the first place.

Do not parse XML unless it's an application requirement. Despite the convenience that it might offer, there are numerous ways to provide equivalent functionalities without opening yourself to these vulnerabilities.

What's Next?

It should go without saying that protecting our platforms against the exploits of bad actors requires an expansive knowledge of the technology and infrastructure in use.

Nevertheless, if you're in charge of a highly productive team with many responsibilities and pressure on your hands, it's essential to do your best to offer them the tools and mechanisms to perform their best. That's not an easy task.

Luckily, we've developed the ideal solution for you.

Our dynamic application security testing solution is a fantastic and powerful solution that empowers teams focused on delivering the best solutions on the web while protecting your users.

You can check it out here.

StackHawk Releases First of its Kind Integration with Snyk that Correlates Dynamic and Static Application Security Testing

StackHawk

DENVER, Colo. - April 27, 2022 - StackHawk, the company making application security testing part of software delivery, has released its official integration with Snyk, the leader in developer security. The new integration correlates findings across StackHawk’s dynamic application security testing (DAST) tool and Snyk’s static application security testing (SAST) tool to provide developers with a significantly more efficient way to find, correlate, and fix application and API security vulnerabilities. The integration was released as StackHawk joined Snyk’s new Technology Alliance Partner Program (TAPP).

“Our integration with Synk provides users, for the first time, the ability not just to use both DAST and SAST side-by-side, but to use them in a fully integrated way. By unifying the tools, developers can identify which issues are most critical to fix and which line of code needs to be modified for significantly faster remediation,” said Joni Klippert, CEO, StackHawk. “In a world where applications and APIs are the top attack vectors, enabling developers to fix vulnerabilities as part of their workflow, before an issue hits production, is critical for both small and large organizations.”

“We love to see how StackHawk is empowering developers to build quickly and securely as part of our partnership,” said Jill Wilkins, Sr. Director, Global Alliances, at Snyk. “The new Snyk and StackHawk integration is a direct advancement of our collaborative mission to help businesses successfully manage risk, without sacrificing the efficiencies of modern application development methodologies.”

Joint customers are already seeing benefits of implementing developer-first security testing and DevSecOps within a single platform. AngelEye Health noted how the StackHawk and Snyk partnership gives developers a unified look at the security risks in their applications and APIs, without needing to jump across user interfaces (UIs).

“We were looking for DAST and SAST tools that would give our developers a complete understanding of application and API security issues in our apps,” said Jay Maples, director of IT operations at AngelEye Health. “We quickly realized giving them findings across multiple tools and UIs wasn’t going to work. Using the new StackHawk and Snyk integration gives our developers the whole picture of what application security issues exist, which issues are most important to fix, and how they can quickly remediate them.”

Built for modern applications, the StackHawk platform is fully automated in CI/CD, making it easy for developers to roll out software fixes quickly, securely and efficiently. To learn more about the Snyk integration attend the webinar on May 4, 2022 at 10 AM PT. Register here: https://sthwk.com/snyk-webinar

About Snyk

Snyk is the leader in developer security. We empower the world’s developers to build secure applications and equip security teams to meet the demands of the digital world. Our developer-first approach ensures organizations can secure all of the critical components of their applications from code to cloud, leading to increased developer productivity, revenue growth, customer satisfaction, cost savings and an overall improved security posture. Snyk’s Developer Security Platform automatically integrates with a developer’s workflow and is purpose-built for security teams to collaborate with their development teams. Snyk is used by 1500+ customers worldwide today, including industry leaders such as Asurion, Google, Intuit, MongoDB, New Relic, Revolut and Salesforce.

About StackHawk

Introducing StackHawk’s New Snyk Code Integration

Joni Klippert

Today is a big day at StackHawk! We are thrilled to share that our integration with Snyk Code, the leading developer-friendly Static Application Security Testing (SAST) tool, is now live.

In addition to the integration, StackHawk is also an inaugural member of Snyk’s new Snyk’s Technology Alliance Partner Program (TAPP).

This news all builds upon our partnership with Snyk that we announced in early April of 2022.

Correlating DAST and SAST To Shorten the Find-Fix Cycle

StackHawk and Snyk began informally working together in 2021, supporting customers looking for a comprehensive suite of developer-centric application security testing tools. With these customers, the value of combining Snyk’s power to identify vulnerabilities in underlying code with StackHawk’s ability to find vulnerabilities in running applications quickly became obvious.

And so the StackHawk product team set out to create an integration with StackHawk’s Dynamic Application Security Testing (DAST) tool and Snyk’s Static Application Security Tools (SAST) tool.

But, we knew that in order to have a real impact, we couldn’t just surface security issues from StackHawk’s DAST tool and Snyk’s SAST tool in a UI and stop there. Legacy vendors have offered this capability for years, and it’s clear that showing two sets of findings in one screen drives minimal value. Teams spend hours comparing findings across the two tools, and are forced to try to manually correlate these issues.

Instead, we needed to create something that harnessed the best parts of both of these tools and correlated the findings from a StackHawk test with the findings from a Snyk test - while keeping the developer at the forefront of product innovation.

The Magic of DAST + SAST

We love DAST because it finds the vulnerabilities in your proprietary code that are exploitable by bad actors. This means DAST findings should be teams’ top priority to fix. But, because DAST tests the running app, required fixes can take more effort to fully understand.

We knew that if we layered SAST’s ability to triangulate vulnerabilities down to the line of code with the benefits of DAST, we could unlock tremendous value. Teams would know where to focus their attention and they would be able to dive right into the code to fix issues rapidly.

Bringing Our Vision for DAST + SAST to Life

The new integration from StackHawk and Snyk does what no other DAST and SAST partnership has accomplished – application and API security issues are now correlated across the two tools.

What this means in practice is that when StackHawk’s DAST tool finds an exploitable vulnerability and Snyk’s SAST tool identifies that same issue, the vulnerability request and response information from StackHawk is reconciled with the exact line of code causing the issue from Snyk.

By doing so, teams get three huge benefits that make application security testing much more efficient:

Prioritization: Findings are validated by two testing methodologies, so teams have less noise in the system and know which findings are most crucial to fix.
Accelerated Fix: By pointing to a specific line of code, developers have all the information needed to fix on their own as part of their usual workflow
Streamlined Workflow: Developers can get all the information they need to understand and fix security issues in a single place without context switching or jumping across UIs

Our customer, Jay Maples, the Director of IT Operations at AngelEye Health said it best:

“Using the new StackHawk and Snyk integration gives our developers the whole picture of what application security issues exist, which issues are most important to fix, and how they can quickly remediate them.“

Try It and Decide For Yourself

If you are interested in trying this integration for yourself, check out our docs which will walk you through deployment and configuration of this new integration or check out our quick demo video 👇

video

To get scanning, all you need is a StackHawk and Snyk account. Getting started with StackHawk is free.

If you aren’t quite ready to deploy on your own but want to learn more, check out our webinar that features StackHawk’s Chief Security Officer, Scott Gerlach, and Snyk’s Tomas Gonzalez. The two of them will walk you through the integration.

Spring Broken Authentication Guide: Examples and Prevention

StackHawk

Broken authentication vulnerability was recognized as one of the OWASP's top 10 vulnerabilities.

Broken authentication vulnerability essentially is when an attacker gains unsolicited access to restricted data and/or functionality. It can lead to identify theft, data leakage and, in worst-case scenarios, give total control of the compromised system to the attacker.

This post will cover broken authentication vulnerability in general and in Java Spring in particular.

What Is Broken Authentication Vulnerability?

Broken authentication means an attacker can gain access to restricted data by pretending to be a different user. The attacker provides the authentication credentials of a different user and logs in to the system.

In this way, the attacker gains access to all the data and functionality of the user he pretends to be. For instance, if an attacker provides the credentials of the admin user, he'll have total control over the compromised system.

What Causes Broken Authentication Vulnerability?

There are many things that can result in a broken authentication vulnerability. Let's review some of them.

Using Weak and Standard Passwords

This is obviously a bad idea. If the username and password for your admin panel are "admin" and "admin," an attacker can easily guess them. The same is true if you use "admin" for the username and "12345" as a password.

This seems to be trivial, but it's actually not. Hackers have broken into a lot of systems in the past because of weak passwords.

Allowing Brute Force Cracking

If you change the credentials to something stronger—let's say "us8234243" for the username and "2ukZ3fav" for the password—those credentials can still become compromised.

One way an attacker can gain those credentials is via brute force cracking. In other words, the attacker creates an automated script that uses different combinations of usernames and passwords sequentially until he finds the right combination. This process can be very time-consuming (days, weeks, or even months), but if you don't prevent this kind of attack, it's still doable.

Sending Credentials in an Insecure Way

Even if you use a strong password and prevent brute force attacks but send the credentials to the server in plain text using an unencrypted connection (HTTP and not HTTPS), any other user who's connected to the same network as you can eavesdrop. Once he has the credentials, he can log in as if he were you.

Improper Session Handling

Improper Session Storage

Since the HTTP protocol is stateless, there's some need for session management between the client and server. Essentially, what we need is a way to identify the user and its state between distinct requests to the server. This can be done in various ways, some of them less secure than others.

For instance, after a successful login, we can save the credentials in a file (cookie) on the client's device. In subsequent requests, we can send this cookie to the server. This way, the server will know that the user is authenticated and identify him.

However, unencrypted cookies can be eavesdropped as easily as a username and password.

Improper Session Timeout

It's important to set a timeout for our login session. This means that after a certain period of inactivity, the user is automatically logged out from the system. Failing to do so may result in session hijacking.

This means that a session lasts forever. Hence, even if the cookie is encrypted, copying the cookie to another machine can allow an attacker to log in to the system.

Exposing Session Identifiers

Another way in which an attacker can compromise a session is by seeing the session identifiers in the URL. During this process, anyone who has the link can enter the login session.

For instance, if we store the session info in a URL of this structure—https://domain.com/login?username=test&password=test—anyone who has the link can log in to the system. This is bad practice.

Failing to Secure API Routes

In an API, there's usually a way to define which routes should require an authentication and which should not.

If you fail to add an authentication requirement for a route that should contain it, the functionality behind this route will be available worldwide. More on this later.

Click here to learn about more reasons for a broken authentication vulnerability and additional info on this vulnerability in general.

Mitigating Spring Broken Authentication Vulnerability

Here, I'll first discuss mitigating a vulnerability in general and then touch on mitigating the vulnerability in Java Spring.

Substantially reducing the risk of compromising the system due to this vulnerability is usually quite straightforward.

Credentials Handling

Here are some best practices:

Don't use default passwords (admin/123123).
Avoid using keyboard sequences (qwerty, 123456).
Use a password rotation policy (change the password every X weeks).
Don't disclose your passwords to others.
Don't log in to a website that uses an unencrypted connection (HTTP instead of HTTPS).

Brute Force Prevention

Here are some best practices:

Limit failed login attempts.
Log all failures and alert administrators when multiple failed requests happen in a short time span.
Ban IP addresses that generate failed login attempts from logging in to the system.

Session Handling

Here are some best practices:

Don't store credentials on the client's side, especially in an unencrypted way.
Store the session identifiers on the server.
Limit the session duration and invalidate the session after a logout.

Don't send session identifiers in a URL.

Spring Boot

The Spring framework is a superb Java framework for creating web applications and enterprise applications.

In 2005, Pivotal developed the Spring framework, and it's still very popular today. Ever since Pivotal developed the Spring framework, they've added various modules to the core Spring container.

Spring Boot is one of the most commonly used ones, representing the convention over configuration part of the Spring framework. Spring Boot lets you code with very minimal configuration.

Mitigating Broken Authentication Vulnerability in Spring Boot

Although the actions that describe vulnerability prevention in terms of credentials handling are quite framework agnostic, there are some specifics in securing routes in Spring Boot.

Securing Routes

Example of Vulnerability

This Spring controller doesn't explicitly enforce any authentication:

@RestController @RequestMapping(path = "/administrator") public class AdminEndpoint { @PostMapping(path = "action") public ResponseEntity doAdmin() { // ... } }

Additionally, in this example below, we have only one route that we've marked as requiring authentication:

The right way to protect routes in Spring is to mark any route except the public ones as requiring authentication:

.antMatchers(HttpMethod.GET, "/public/**").permitAll(); .anyRequest().authenticated();

Conclusion

Broken authentication vulnerability is a serious threat to application and website developers, administrators, and owners. It can result in data theft and identity theft and may make the whole system totally comprised.

Various things can cause this vulnerability, including having weak credentials, allowing brute force attacks, conducting improper session handling, and failing to secure API routes.

Luckily, most of the mitigation techniques are simple and straightforward. If you use these techniques, the risk decreases substantially. Most of those techniques are framework agnostic and can apply to all frameworks equally, including Java Spring Boot.

However, there are some specifics in the way routes should be handled in Spring Boot, and I've described them in this article. Make sure to protect all routes except the public ones, and you'll be on the safe side.

Django XML External Entities (XXE) Guide: Examples and Prevention

StackHawk

XML External Entity (XXE) attacks are a way to bypass security firewalls and coerce an application into downloading a threat to itself or sharing information with an attacker. These attacks often lead to loss of confidential information and denial of service outages.

In this article, we'll look at Django XML External Entities and how you can protect yourself from XXE attacks in Django.

XML External Entity Attacks

XXE attacks are injection attacks that take advantage of an application's willingness to process dangerous XML documents.

These documents use XML constructs to interfere with the application's expected behavior.

Before describing how these attacks function, we should discuss how we form XML documents. They're comprised of entities that hold or refer to content. If they already have their content, they are internal entities. If they don't, they contain a pointer to content elsewhere; they're external entities.

Since you're already familiar with the Internet and blogs, you already know what a URL is. Many XML external entities use URIs, which are a superset of URLs. They look a lot like links in HTML pages, but they can point to a wide variety of different resources. URIs may refer to content or resources—entities—on the host running the application or elsewhere, like the local network or the public Internet.

XXEs can also refer to content contained in the document itself. This can include constructs such as dictionaries that map entities to terms. Even they can be used in an attack, as we'll see below.

The Anatomy of an Entity

Let's look at a document with an external entity.

This document defines an external entity on line #5 in the DOCTYPE attribute. The entity's name is xxe and points to an external website at https://example.com/login.

So, when the document's body refers to &xxe, an XML parser that expands external entities will retrieve the contents of https://example.com/login and insert them in the document between the <bar> tags.

XML Entity Attacks in Action

Now that we know what an XXE looks like let's examine a few of the more common flavors of XXE attack, then see how they look in Django.

Malicious Data Injection

If an attacker can coerce your application into retrieving data and inserting it into a document, they can add malicious content like phishing forms and URL redirects.

So, our example entity is a potential injection attack. It's inserting a login form to someone else's website.

Network Snooping Attacks

External entities don't have to point to the public Internet. They can point at internal addresses, too.

So let's change the URI in our sample entity:

If this URL exists, its contents will end up in the document. If it doesn't, an attacker can still learn a lot. Does the 10.1.1.* network exist in your network? Does the 10.1.1.1 host exist? Is it running a webserver? This may sound like a lot of work until you realize that you can build a few thousand of these documents with a Python script and a few minutes to spare.

File Retrieval Attacks

Now, let's make a small tweak to our attack.

Instead of retrieving data from a web server, this attack inserts the contents of /etc/hosts into the tag. Now the attacker knows what your application server does about its network.

Denial of Service Attacks

Not all files are created equal. While some file retrievals are useful for stealing information or planning for deeper attacks, others are useful for Denial of Service (DOS) attacks.

The /dev/random file generates random numbers based on system noise. It's a Unix special file. Reads to this file block: they don't return data until the system sees noise it can use to generate a random number. As a result, you can freeze an XML parser by pointing it there. Send a few hundred of these documents, and you've effectively killed the web application.

LOL U R Pwned

Let's look at one last attack before covering how to protect your Django application from XXE attacks. This one takes advantage of XML parser behavior to create a denial of service.

Here's an example of the billion laughs attack:

What happens when an XML parser process this document?

It encounters the &lol9; entity.
This entity contains 10 &lol8; entities.
Each &lol8; entity has 10 &lol7; entities.
Wait...each &lol7; has 10 &lol6; entities?
And each &lol6; has 10 &lol5; entities!
Keep going, and we end up with 109lols!

So, that's literally a billion laughs. As a result, a tiny XML document expands to a few gigabytes of memory when processed.

Avoiding Django XML External Entities

How do you avoid these attacks if your Django application needs to parse untrusted XML? Quite simply, it turns out. The defusedxml python package does all the work for you. Update a few import statements, and it'll throw an exception when it comes across a forbidden construct.

No Laughs for You

Let's start with a billion laughs. Put the XML above in a file named lolz.xml, then point this code at it. You'll need a Python environment with defusedxml installed.

This code uses the standard Python ElementTree parser, wrapped in defusedxml's protection. Instead of importing it from ElementTree, we specified defused's wrapper. After parsing the document, the code walks the document's child nodes and prints them—if it gets there. If processing the document throws, we print out the exception to see why.

But here's the output:

EntitiesForbidden(name='lol', system_id=None, public_id=None)

Defusedxml refused to parse the document! It saw the first Entity declaration and threw an appropriate exception.

No File Retrievals

Let's put the file retrieval XML in a file named files.xml and point the parsing code at it.

The output looks similar to the previous trial:

EntitiesForbidden(name='xxe', system_id='file://etc/hosts', public_id=None)

Just like before, defusedxml stopped parsing when it saw an entity declaration.

Defusedxml Protects You From XXEs

These examples are using defusedxml's ElementTree interface. It also offers interfaces for cElementTree, expatreader, sax, minidom, pulldom, and several other XML parsers and builders. So, it's very easy to plug it into existing Python apps by updating your imports. If you need to write new code, you can still use the interfaces you're accustomed to.

No More Django XML External Entity Attacks

XML External Attacks are dangerous constructs that can take your application down and steal your client's data.

You need to protect yourself from them. In this post, we discussed what the attacks look like and then saw how easy it is to protect your Django sites with defusedxml without modifying much more than a few import statements.

Now that you understand Django external entity attacks check your code and make sure you're safe. While you're at it, sign up for a free account and take your code security to the next level!

Spring Broken Object Level Authorization Guide: Examples and Prevention

StackHawk

If a malicious user gains access to functionality that only system administrators should have access to, there can be dire consequences. This post is about a specific type of vulnerability called broken object level authorization, or BOLA. This happens when an attacker gains access to API methods that should be restricted. In addition to talking about what this is, I'll discuss ways to mitigate this attack in general, and specifically in Java Spring Boot.

Broken Object Level Authorization Defined

Back-end APIs are basically a set of functions that return answers to requests. For instance, if we run an e-commerce shop, API will handle many functions. Some examples include getting the product description, getting the product inventory, setting the product price, adding the product to the shopping cart, checking out, and sending an invoice, among other things. Some of those actions should be accessible to every user who reaches the store, whether it's an application or a website. For example, all users should be able to get product details, get product category details, and view the shipping policy page.

On the other hand, other actions should be strictly performed by specific users only. For instance, shop administrators should be the only ones who can update product inventory or set a product price. Only specific store shoppers should be able to add a specific product to the cart and check out with their order.

If the store developers don't enforce proper permissions on those actions, serious consequences can occur.

For example, a malicious actor will be able to add products to a cart in the name of an existing client. Or they can change the shipping address and pay for them with the existing client's payment method. Moreover, if the malicious user successfully accesses functionality that only the store's administrator should be able to manage, the consequences might be much worse. We call this vulnerability broken object level authorization.

Technical Specifics of a Broken Object Level Authorization Vulnerability

As described above, broken object level authorization is basically a vulnerability that allows an attacker access to restricted data or functionality. Now let's see how it happens in detail. Usually, APIs use URLs of the following structure to access specific resources of items: http://domain.com/api/version/resource/sub-resource/id. In addition, the ID of the resource can appear in the header of the request or in the body instead of the URL. In any case, to access a certain resource, each user generally needs to undergo two steps: authentication and authorization.

Authentication

Authentication basically means logging in. The system receives a combination of a username and password or an API access token and then validates those credentials against the data that it stores. If users enter the correct credentials, they can log in and do API requests.

Authorization

However, authentication is not the full story here. It's just the first step. Being authenticated just means that the API "knows who you are." It doesn't mean that you can actually do requests to API endpoints. This stage is authorization. Each user can have different privileges grouped into a "role," and each endpoint can have granular permissions. For instance, an endpoint that accesses a product page will allow all users to view the data, but only the store admin can edit anything. Basically, there should be a check for each API call if the user who has issued it has access to the endpoint and has permission to do the specific action.

Implementing Authorization

A developer can implement authorization in different ways. For instance, we can send the API_token with each request. The API code will check the API_token against the action the user wants to perform and the token's permissions list. Alternatively, we can store the permissions in an encrypted way on the client side. Then it can be sent over to the server with each request.

Breaking Into the API

The specifics of how an attacker can break into an API are application specific.

The general idea, as stated above, is to gain privileges to restricted data or actions. Hijacking the API_TOKEN can be easily done if the API token is sent as part of the URL request: http://domain.com/api/version/resource/sub-resource/id?api_token=randomApiToken1422345. Alternatively, an attacker can do it by copying an encrypted JSON web token from a client machine. However, in most cases, this is just human error when API developers don't properly check the permissions on their end.

Spring Boot

The Spring framework is a superb Java framework for creating web applications and enterprise applications. In 2005, Pivotal developed the Spring framework, and it's still very popular today. Ever since Pivotal developed the Spring framework, they have added various modules to the core Spring container. Spring Boot is one of the most commonly used ones, and it is the convention over configuration (CoC) part of the Spring framework. Spring Boot lets you code with very minimal configuration.

Mitigating Broken Object Level Authorization Vulnerability

I'll first discuss how to mitigate this vulnerability in general and then dive into Spring Boot specifics. To mitigate this vulnerability, API developers should first and foremost put authentication and authorization code in place. Without those, any API endpoint is compromised. In addition, proper test cases should cover those mechanisms via unit tests, component tests, and integration tests. Tests should cover at least the most popular and business-critical endpoints. In addition, the tests should cover different use cases. For instance, let's say that a user has entered the wrong credentials. The expected behavior is that no API endpoint can be accessed. The user tries to access an endpoint that they don't have access to. The expected behavior is that access will be denied.

Additional Actions

Verify that each user has specific permissions. If you are deploying a more robust user management system that includes user roles, then make sure that a role hierarchy is in place. For example, an administrator can do all guest actions but not vice versa. Likewise, to prevent request forgeries, don't use an API token as a query param, as in this example: http://domain.com/api/version/resource/sub-resource/id?api_token=randomApiToken1422345. Require API users to refresh their credentials periodically. Don't store permission information in an unencrypted browser cookie on the client's side.

Mitigating Broken Object Level Authorization Vulnerability in Spring Boot

Luckily, Spring Boot has Spring Security. This is a robust and built-in way to handle authentication and authorization, thus preventing this vulnerability. Since Spring Security is very robust and has lots of configuration options, we can't cover all of it here. However, it is sufficient to point out that it provides you with BOLA mitigation out of the box. We can use this snippet:

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency>

This enables Spring Security in our application automatically. This configuration protects our endpoints by default. And we need to manually set permissions for each endpoint to make it accessible to users. This is a good starting point for developing any new API in Spring Boot. Having said that, users have to take into account that Spring Security can have a steep learning curve. It can also be overkill for their needs. If you are building a small API, then developing authentication and authorization from scratch can be the right way to go.

Conclusion

BOLA is a serious vulnerability. An attacker can get access to restricted information or functionality. OWASP considers it to be the #1 API vulnerability. Broken object level authorization usually occurs due to human error in API implementation. However, despite its serious impact, its mitigation is straightforward (at least strategy wise) through proper authentication and authorization. Spring comes with a module that handles those out of the box, which, in turn, can make mitigating this vulnerability easier for Spring Boot users.

Vue Broken Access Control Guide: Examples and Prevention

StackHawk

As our leverage grows as productive market members, so do the threats and liabilities we need to mitigate. Therefore, the expertise we need to acquire in order to minimize these threats keeps expanding.

So, to help you keep things manageable, we've created a series of articles tackling the most common security threats and how to address them effectively.

Our articles cover an extensive spectrum of subjects and technologies; no matter your technology of choice, we have an article for you.

For this article, we'll be exploring the topic of broken access control for Vue.js developers.

If you have no experience with any of these technologies, we recommend you take a quick look at this link.

However, we won't be going too deep into specifics, so don't worry too much. A basic understanding of Javascript is required, but it won't take too long to get the hang of it. Plus, you will learn some really cool stuff.

Alright. Moving on.

Explaining Access Control

Access control, also referred to as authorization, pertains to a set of policies and mechanisms that govern access to digital resources.

The normal authorization flow takes place once the server has determined your credentials through an authentication mechanism. It then follows by granting or restricting what resources a user has access to by controlling privileges and routes to resources and endpoints.

Despite their similarities in the process of protecting and gatekeeping resources, it's important not to confuse the role of authentication with that of authorization. Strictly speaking, authentication is the act of determining a user's identity. On the other hand, authorization is the act of determining whether a user has access to a resource.

Additionally, authorization infrastructure is commonly the backbone for user tracking and resource monitoring.

Implementing a trustworthy and reliable access control system is a very intricate and misleadingly challenging task since it is so intimately tied to the architecture of your system.

Depending on the scale and sophistication of your system, an acceptable solution could mean implementing a complex authentication mechanism, a third-party library, or a combination of both.

Broken Access Control

As you might have imagined already, "broken access control" refers to the act of breaching your system's access control (hence the "broken" part of the term).

It goes without saying that a breach of your access control mechanism is a significant concern for your security. This event could be disastrous to your business and the users who use your service. Knowing that a single successful breach could provide a bad actor with control over your platform, it is essential to address any vulnerability found.

Common Broken Access Control Vulnerabilities

Broken access control vulnerabilities can present themselves in many different ways.

Insecure ID Vulnerability

Modern websites use some form of ID to quickly and efficiently retrieve data. However, if these IDs are easy to figure out, there is a potential vulnerability.

To illustrate, imagine you have a profile page section where the user profile is displayed. Then the following URL retrieves our user profile.

https://www.supersecure.com/profile?id=123

By changing the number in this query string, I can access any profile. That's the kind of threat you face when no active access control is in place.

Path Traversal Vulnerability

Path Traversal refers to the ability to navigate a filesystem's directory. Without proper access control, your system might be victim to Path Traversal exploits, allowing bad actors to access restricted resources on the server.

To illustrate, please refer to the following URL.

https://www.supersecure.com/photos?file=user.png

When the path of a resource in the system can be modified by the user and is not adequately validated, this is a potentially vulnerable point. For example, if you were to change 'user.png' to something like '../../src/secrets', we could access the application secrets.

File Permission Vulnerability

Typically, web applications include vital configuration files and resources that should not be accessible by users. However, an attacker can target these files if there is a poor implementation of configuration policies.

In this case, File Permission vulnerabilities are vulnerabilities in the server's permission mechanism.

To illustrate this, here is an example.

https://www.supersecure.com/photos?file=../../secure.json

In this case, the attacker is requesting our application to retrieve a file that it's not supposed to retrieve.

Implementing Proper Authentication

The first thing you need to do is make sure that you have implemented proper authentication in your application.

We will be using the Auth0 service to provide a robust authentication solution.

Here's a quick refresher on how to implement Auth0 on your application from ourprevious article on the subject.

First, go to the Auth0 website and register a new application. If you don't have an Auth0 account, you can sign up here.
Once in the Auth0 dashboard, go to the Applications section and click on the Create application button. Input a name for your application and make sure to choose Regular web applications as the application type.
Lastly, click the Create button.
After creating the application, go to the Settings tab and get your Auth0 domain and client id. Then, set Allowed callback URLs to https://localhost:8080/callback and Allowed logout URLs to https://localhost:8080/.
The first URL tells Auth0 where to redirect the user after authentication, and the second URL tells Auth0 where to redirect the user after logout.

Finally, save your changes.

Now, go to your project's root folder and create a file called "appsettings.json" there. Then, add the following code and update YOUR_DOMAIN and YOUR_CLIENT_ID with the corresponding values from the Auth0 dashboard.

{ "domain": "YOUR_AUTH0_DOMAIN", "clientId": "YOUR_AUTH0_CLIENT_ID", "audience": "", "serverUrl": "" }

That's it.

Addressing Broken Access Control Vulnerabilities

Addressing broken access control vulnerabilities requires making a few simple adjustments to our platform.

Insecure IDs

To address insecure IDs, we need to ensure we have implemented GUIDs as our IDs so they are not easily guessable.

In addition, IDs belonging to sensitive resources must be unique and obfuscated.

Of course, this requires a significant change if you have not done so beforehand, but it's critical to make this change as it is the most fundamental security measure we can take.

Path Traversal

In order to mitigate path traversal attacks, we must validate all user inputs and restrict access to resources as much as possible.

A simple way to do this would be with the following check:

var rootDirectory = '/var/www/'; var path = require('path'); var filename = path.join(rootDirectory, userInput); if (filename.indexOf(rootDirectory) !== 0) { return respond('ACCESS DENIED'); }

This filename variable contains the name of a validated file or directory.

File Permission

Vue.js and Node.js do everything that needs to be done in this regard, so you don't need to do much to stay secure. Nevertheless, you should consult your security manager if you need to tinker with these settings.

Conclusion

It is hard to argue with the notion that in terms of productivity and capacity to create wealth, no career compares to software development. Creating products and services that reach mass adoption and bring immense change has never been this easy, and with that power comes great responsibility.

Creating elegant and robust solutions is now a cakewalk with Node.js and Vue.js. Nevertheless, it is essential to understand that, despite these technologies' enormous leverage and versatility, it is still crucial to keep an eye on our security.

We recommend considering our dynamic application security testing (DAST) solution for your team.

Our DAST runs security tests against your running application in real-time, finding vulnerabilities your team might have introduced and exploitable open source vulnerabilities in your libraries.

You can check it out here.

Spring XML External Entities (XXE) Guide: Examples and Prevention

StackHawk

XML is a markup language that we use to define and categorize data. Data stored in XML format can move between multiple servers or between a client and a server.

Once a server receives an XML input, it parses it via an XML parser. XML external entities are basically references in the XML document to files or URLs outside of the XML document. Essentially, it's an XML standard feature that enables accessing and/or loading external resources.

However, this feature can be dangerous, as it can allow malicious actors to retrieve unauthorized sensitive data, server-side request forgery attacks, and file contents.

What Is XXE?

XML documents adhere to a certain standard. This standard highlights how the XML document should be constructed, outlines what differentiates a valid XML document from an invalid one, and so forth.

The standard also specifies a term called "entity." An entity is a placeholder for some content.

Entities can be internal or, as in our case, external.

Entities are accessed via a system identifier. This identifier is a pointer to a location. It can either be a file or a URL. The standard specifies what should happen when an XML parser software accesses this entity.

It fetches the file/URL that's pointed by the system identifier and replaces the system identifier with the contents of the file/website. For instance, if we have an XML document that looks like this:

The contents of this line

&xxe;

will be replaced with the contents of the passwords file at file://etc/passwd, which can look like this:

Thus, this scenario discloses sensitive user information. Note that this is not a bug, but it's a feature in the XML specification. The problem arises when the parser allows executing XXEs and we don't validate the input we receive from the client.

We'll cover this more in depth later.

Real-World Example

Let's assume you're browsing an e-commerce website. To retrieve the specification for a certain product (size, weight, price, etc.) the client (in this case, our browser) sends an XML to the server with the product's ID:

<?xml version="1.0" encoding="UTF-8"?> <product>1478</product>

The server, in turn, should return a response similar to this one:

However, if the server doesn't validate the input properly, we can emulate the client's call and send the following payload instead:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <product>&xxe;</product>

This will result in the following response from the server:

Invalid product id: alexander:x:1000:1000:Alexander:/home/alexander:/bin/bash flatpak:x:978:976:User for flatpak system helper:/:/sbin/nologin jenkins:x:977:975:Jenkins Automation Server:/var/lib/jenkins:/bin/false nginx:x:976:974:Nginx web server:/var/lib/nginx:/sbin/nologin redis:x:975:973:Redis Database Server:/var/lib/redis:/sbin/nologin mysql:x:27:27:MySQL Server:/var/lib/mysql:/sbin/nologin systemd-oom:x:967:967:systemd Userspace OOM Killer:/:/usr/sbin/nologin

SSRF XXE

In addition to compromising file contents, an XXE can be used to create server-side request forgery.

In reference to this line in the example above

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>

if the attacker replaces it with a call to an external URL,

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://malicous-code.com"> ]>

this will make the server call the URL address.

If we incorporate the response from this server further down the XML document, it essentially will cause the server to respond with the response from the malicious website and not the intended response.

In turn, this can cause serious implications for this application's end user.

Consider a website that responds with a form to enter a username and password. If this form was generated due to an SSRF caused by an XXE, the attacker can get the website user's credentials.

Mitigating XXE Vulnerability

Now that we've discussed what XXE vulnerability is, let's see how we can mitigate this risk in Java and Java Spring.

Java and XXE

As said in the OWASP XXE cheatsheet, "Java applications using XML libraries are particularly vulnerable to XXE because the default settings for most Java XML parsers is to have XXE enabled. To use these parsers safely, you have to explicitly disable XXE in the parser you use."

As previously said, XML parsers parse XML documents. To mitigate XXEs, we either need to validate all input, which can be time consuming and tedious, or disable parsing external properties in XML documents entirely.

Since most configurations in Java applications are now done with Java annotations and not XML, the rule of thumb recommendation for mitigating XXEs is to disable XXE processing entirely.

Java Spring

The Spring framework is a popular Java framework for developing enterprise and web applications. Originally created in 2005 by Pivotal, it's still going strong today.

As XML was in its height of popularity around 2005, Spring originally based its configuration entirely on XML. The original Pivotal developers used XML throughout the system for everything from defining Java beans to configuring the database connection to defining object dependency injection.

Although the Pivotal developers have replaced XML configuration gradually in Spring in favor of Java-based annotations, it's still fully supported and can be found in abundance in old Java enterprise applications. Hence, that explains the increased importance of mitigating XXE vulnerabilities in Java Spring.

Mitigating Spring XXE

Luckily, Spring has XXE parsing disabled by default. This means that you're covered in the vast majority of cases. However, there are two caveats to this statement:

There are many XML parsers you can use in Java, and if you use an XML parser that doesn't come bundled by default with Spring, you might need to manually disable XXE or carefully validate the input and make sure that you trust the source the entities come from.
Several versions of Spring had XXE vulnerabilities in the past. Basically, those versions had XXE enabled by default. So, if you're using one of those versions, you need to upgrade as soon as possible to a patched version. As stated on the OWASP website, the affected versions are

3.0.0 to 3.2.3 (Spring OXM and Spring MVC),
4.0.0.M1 (Spring OXM), and
4.0.0.M1-4.0.0.M2 (Spring MVC).

To fully address these issues, you need to upgrade to Spring Framework 3.2.8+ or 4.0.2+.

Note that another way to avoid the XXE issue altogether is to use a different format for sending messages between multiple servers or between client and server.

In recent years, the most popular format is JSON, which doesn't introduce these kind of vulnerabilities. Likewise, you can replace XML-based SOAP APIs with simple HTTP REST APIs, which don't usually use XML.

Conclusion

XML is a useful format for defining and representing structured data. As part of the XML standard, it's possible to import entities from external resources.

Although this can be a useful feature, it also possesses a security risk. Malicious actors can inject their values into the XML, and if the server is not hardened, the system can become compromised.

Files can be stolen, and server response can be forged. Java applications are especially vulnerable to such attacks, as most Java XML parsers allow parsing XXE entries.

Spring is a popular Java framework. Fortunately, it comes with XXE parsing disabled. However, XXE was enabled in several Spring versions in the past. Lastly, if you use an XML parser other that the one built in with Spring, you'll need to manually validate the input or disable XXE parsing.

This post was written by Alexander Fridman. Alexander is a veteran in the software industry with over 11 years of experience. He worked his way up the corporate ladder and has held the positions of Senior Software Developer, Team Leader, Software Architect, and CTO. Alexander is experienced in frontend development and DevOps, but he specializes in backend development.

Snyk and StackHawk Announce Partnership to Provide Complete Modern Application Security Testing Suite

Rebecca Warren

Complete application and API security test coverage requires the implementation of Dynamic Application Security Testing (DAST), Static Application Security Testing (SAST) and Software Composition Analysis (SCA). Historically, teams embracing DevSecOps by integrating automated security testing into the early phases of software delivery have been forced to choose between legacy platforms offering all three types of tooling, or implementing best-in-class point solutions. With this new partnership, engineering teams now have the possibility to seamlessly implement modern, developer-first tooling across all three types of testing.

“Software development has rapidly accelerated over the past decade and the majority of security tools on the market have not kept up,” said Joni Klippert, CEO, StackHawk. “When code is being pushed to production multiple times per day, security tools need to surface vulnerabilities early in the development process to the developer writing the code. By using StackHawk and Snyk together, teams get continuous security testing across their entire software delivery pipeline. This means shipping better quality code without sacrificing delivery times or interrupting sprints.”

The companies are now formalizing their partnership after seeing significant momentum across joint customers throughout 2021. For instance, Breathe Life, an insurtech startup, was looking for security tooling that could keep pace with its engineering team when it discovered StackHawk and Snyk’s complimentary offerings.

“We wanted security to be a shared responsibility across the organization. So we needed to provide our team with the tooling and best practices so all teams could do that,” said Francois Allard, Director of Engineering, Breathe Life. “With StackHawk and Snyk, I can breathe more and people on my team can breathe more. It allows us to have more confidence in what we're building and that we don’t have those obvious vulnerabilities.” ”

“Snyk seeks to empower the millions of global developers that are building our future to also have the control via the right tools to secure it,” said Carey Stanton, SVP of Global Business and Corporate Development, Snyk. “By partnering with the talented StackHawk team, more modern DevSecOps teams worldwide will now benefit from easily implementing tooling designed for and by developers for DAST as well as SAST and SCA.”

Those interested in learning more about how the tools work together can see StackHawk and Snyk in Action by watching the webinar here.

About StackHawk StackHawk is making application security testing part of software delivery. The StackHawk platform empowers engineers to easily find and fix application security bugs at any stage of software development. With a strong founding team that has deep experience in security and DevOps, and some of the best venture investors in the business, StackHawk is putting application security testing into the hands of engineers. Learn more and sign up for a free trial at www.stackhawk.com.

About Snyk Snyk is the leader in developer security. We empower the world’s developers to build secure applications and equip security teams to meet the demands of the digital world. Our developer-first approach ensures organizations can secure all of the critical components of their applications from code to cloud, leading to increased developer productivity, revenue growth, customer satisfaction, cost savings and an overall improved security posture. Snyk’s Developer Security Platform automatically integrates with a developer’s workflow and is purpose-built for security teams to collaborate with their development teams. Snyk is used by 1500+ customers worldwide today, including industry leaders such as Asurion, Google, Intuit, MongoDB, New Relic, Revolut and Salesforce.

Announcing StackHawk and Snyk’s New Partnership

Joni Klippert

Over two years ago, we founded StackHawk to bring application security into the world of continuous delivery. After spending more than a decade building SaaS DevOps solutions that enabled rapid software delivery, it was clear that application security was the next, most important, DevOps frontier. The StackHawk approach to AppSec sought to replace periodic penetration tests and siloed security departments with automation and a shared responsibility for secure code that spanned across engineering, DevOps, and security.

And so, we created StackHawk with the mission to empower engineers to easily find and fix application security vulnerabilities quickly with a modern approach to dynamic application security testing (DAST) and API security.

But, we weren’t the only ones that knew application security had to change. Our friends at Snyk shared the vision of developer-first security, and they went on to create best-in-class software composition analysis (SCA) and static analysis (SAST) tools. Snyk’s products focus on identifying vulnerabilities by looking at the underlying code, whether looking for insecure coding patterns with SAST or vulnerable open source dependencies with SCA. StackHawk tests for runtime vulnerabilities, testing running application services and APIs the same way an outside attacker would. Together, the tools provide complementary testing for a more complete security picture.

In 2021, StackHawk and Snyk began informally to work together, enabling customers looking for a comprehensive suite of developer-centric application security testing tools. Over and over again, we heard from customers that StackHawk’s DAST and API security capabilities, in combination with Snyk’s offerings, provided a complete set of application security tooling today’s teams need.

After seeing significant momentum across joint customers over the past year, we are thrilled to announce that we have decided to formalize our partnership!

StackHawk + Snyk: A Complete Package of Modern Application Security Testing Tools

It is not uncommon for companies to employ a suite of security testing tools for complete coverage. According to Forrester, teams that use SAST and DAST remediate findings 24.5 days faster than the average and teams that combine SAST and SCA scans remediate findings six days faster.

While legacy offerings in market may share the SAST and DAST acronyms, those tools were built to be operated in production by a security team, resulting in long scan times, vulnerabilities existing in production for months, and inefficient (and unacceptable) remediation times. It takes more than a mention of “shift left” on a marketing site to make it a reality.

StackHawk and Snyk are changing that with products that developers love and security teams trust. Here is what customers love about using StackHawk and Snyk together:

Automated Testing in CI/CD

SCA, SAST, DAST and API Security can be automated in CI/CD, alerting developers of security issues early and catching issues before they are shipped to production. Used in combination, StackHawk and Snyk provide greater insight into the exploitability of potential vulnerabilities. When issues are found in the underlying code and are identified as exploitable with a dynamic test, they are clearly worth prioritizing.

Developer Friendly Functionality

Developers are equipped with the information and tools they need to fix vulnerabilities quickly and get back to feature development. Historically, security issues have been identified by a siloed security team long after engineering wrote the code. Engineers would be tasked with fixing previously written code, derailing their planned work. StackHawk and Snyk together offer developers tooling that integrates into their workflow, letting them know when they have introduced an issue and equipping them with the tools to fix it quickly.

Testing for Modern Apps

Snyk and StackHawk were both created for modern apps. Find and fix security bugs in microservices, backing APIs, and modern languages. It is no secret that software development is evolving at a rapid pace. Unfortunately, however, the majority of security tooling on the market was built for the software architectures of more than a decade ago. With modern development languages, microservice architectures, single page applications, and more, today’s software requires up-to-date tooling. Snyk and StackHawk together are leading the charge in their respective categories.

So What’s Next?

We are proud to have formalized our partnership with Snyk so we can continue working together to empower engineers and shift security into the hands of those who code.

In addition to our partnership, we are also thrilled to announce our new integration with Snyk that gives developers the ability to find, correlate, and fix application security issues more efficiently.

If you are looking for more information free to drop us a line. Or, register for our webinar on May 4 at 10 AM PT to see StackHawk and Snyk together in action.

Golang XML External Entities Guide: Examples and Prevention

StackHawk

XML External Entity (XXE) attacks can lead to a denial of service, loss of confidential information, and service outages due. XXE attacks help hackers snoop on systems and compromise critical data. They're a form of injection attack that takes advantage of applications that fail to protect themselves from malicious XML documents.

Let's look at Golang XML External Entities and how Go protects you from this kind of attack.

XML External Entity Attacks

XXE attacks inject applications with XML documents that refer to content that compromise the application's safety or expected operation. In order to understand how these attacks work, we need to take a brief look at how we structure XML documents.

XML documents are made up of entities. Each entity contains or points to content. Entities that contain their content are internal, while entities that point to content outside the document are external. Some external entities use URIs to refer to content or resources on the host system or a network, including the public Internet. Others refer to content in the document description, like dictionaries that map entities to terms.

XML external entity attacks use URIs that point to resources that either compromise the application with malicious content or steal confidential information by coercing the app into retrieving and supplying the attacker with files they shouldn't be able to see. Or, they use entities to generate content that causes code to fail.

XML External Entity Attacks

XXE attacks can take many forms. Let's go over a few more common ones, then see how they work (or not) in Go.

File Retrieval Attacks

External entities point at URIs, and one type of URI is a local file. The attack attempts to get the targeted application to return the contents of the file. Here's a document that uses the URI for the passwd file on a Linux or macOS system:

The DOCTYPE attribute declares that the Document Type Declaration (DTD) for this document follows. This DTD declares two ELEMENTs that can contain any data type and an external ENTITY that refers to "file:///etc/passwd." A file:// URI points to a file on the local system, so this entity is looking for /etc/passwd. We can use this entity anywhere inside the new document by referring to its name; &xxe;.

Then, the body of the document puts the new entity inside the foo and bar tags. The final product would be the contents of the systems' password file inside an XML document.

The contents of the password on modern Linux and macOS systems won't get you passwords, not even the hashed versions, since both systems have moved the hashed passwords out to a location that unprivileged users can't see. But a list of valid users can be useful to snoopers, as are many other files that an unprivileged application can be tricked into retrieving for an attacker.

Network Snooping Attacks

Now that we have a template for creating external entities, we can reuse it for other attacks.

External entities can point at websites, too. So let's imagine an attacker wants to learn about their target's internal network:

If this attack works, it will place the contents of https://192.168.1.1/login inside <bar>.

What if there's no webserver there? Well, now that attacker knows that. What if there is, but /login is a 404? Now the attacker knows to try a different set of URLs. What if the target's internal network is 192.168.2 and not 192.168.1? That's fine; the attacker can keep trying.

Denial of Service Attacks

You can disable or degrade a system with an XXE attack, too.

Let's look at a variation on a file retrieval attack:

The /dev/random file is a special file that generates random numbers based on system noise. It's a blocking file, which means it will not return data until an event it can use to generate a random number occurs. So, pointing an XML parser at it will often cause it to freeze. An attacker that sends a document like this over and over can disable a web service by blocking all of its input threads.

XML Bombs

Before we look at Golang, let's look at one more type of attack. It uses XML parsing to cause a denial of service.

The billion laughs attack takes advantage of XML's ability to nest entities. Here's an example:

Let's go through the process of loading this document:

The lolz contains a &lol9; entity.
An &lol9; entity contains 10 &lol8; entities.
Each &lol8; entity contains 10 &lol7; entities.
Each &lol7; entity contains 10 &lol6; entities.
Each &lol6; entity contains 10 &lol5; entities.
Continue back to &lol1; and you've expanded the &lol9; entity to 109 lols.

As you can see, the billion laughs attack was named accurately. This construct adds a billion copies of "lol" to the XML document. So, a relatively small XML document ends up gigabytes of memory when processed.

Golang XML External Entity Attacks

How do you protect yourself from XXE attacks in Golang? Let's take a look.

Let's start with the file retrieval attack described above:

Here's a simple Go program that parses the document:

This code will print out the name of each element as the parser reaches it. If the element contains text, it will print that next; then, it will print an element's name when it reaches its end. The code also uses a simple CharsetReader to support ISO-8859-1.

Here's the output from the attempt to retrieve the password file:

Successfully Opened retrieval.xml

<foo> <bar>&xxe;</bar> </foo>

Go's XML parser didn't expand the external entity! We get the same result if we run it against the snoop attack above. What's happening here?

Golang's XML decoder doesn't process XML external entities, so these attacks don't work. If you look at issues on Github, the decoder used to fail when it encountered them, but now it simply prints the entity name instead of failing.

So, let's try the Billion Laughs attack.

Put this XML in a file named lulz.xml:

And modify the Go code to open that file name.

Successfully Opened lulz.xml

<lolz>&lol9;</lolz>

Not even a giggle!

So, Golang's defense against external entity attacks is not to process external entities.

Wrapping up Golang and XXE Attacks

This post discussed what XML external entities are and how hackers use them to attack web applications. Then we looked at how these attacks fair against Golang XML processing; not well. Golang's XML decoder doesn't process external entities at all. So, Go applications are resilient against XXE attacks.

But that doesn't mean you can't do more to protect your Go applications from attacks. Sign up for a free account and see how Stackhawk can help you secure your code today!

Rails Broken Object-Level Authorization Guide: Examples and Prevention

StackHawk

In this article, we'll discuss rails broken object level authorization vulnerabilities and how bad actors use them to exploit your systems.

Firstly, we will define what broken object-level authorization is and how it differs from other authorization attacks. Then, we will provide some examples of the most commonly used broken object-level authorization attacks. Finally, we will leave you with some actionable steps and guidance to mitigate this threat and protect your systems.

By the end of this article, you'll know what broken object-level authorization is and how it affects systems all over the net. Additionally, you will be able to spot vulnerable spots in your systems and have the knowledge and expertise to address them.

Before we start, we want to clarify that this article is aimed at Ruby on Rails developers. With that out of the way, let's jump in.

What Is Broken Object-Level Authorization?

Before we address the big question, I think it's essential that we understand what authorization is and the nuance behind it.

In the context of software security, authorization is the mechanism that provides or denies access to resources in a system. Its main job is to ensure that only the people and services authorized to access these resources (data, mainly) can do so. This means that without a proper and robust authorization mechanism, all data in a system is at high risk of falling into the wrong hands.

Authorization is sometimes confused with authentication since they serve a similar purpose in gatekeeping access. However, they are very different systems that are designed to fulfill roles beyond just access protection.

Authorization systems are basically the policy enforcement mechanism for your application. They provide the infrastructure to maintain confidence in the security of your system between users. On the other hand, authentication is mainly concerned with keeping non-users out.

Alright, now let's address the big question. What is broken object-level authorization?

Broken object-level authorization, or BOLA, is a specific attack that targets weak or poorly implemented authorization mechanisms. It exploits endpoints that allow user input to retrieve objects (data) and have no user authorization validation.

In essence, an attacker can exploit your application whenever it doesn't properly confirm that the user requesting a resource has ownership of the said object.

How It Differs from Other Authorization Vulnerabilities

This is different from other authorization attacks like, for example, broken authentication because the target is not to gain access to the system but to resources within the system.

In the case of BOLA attacks, the targets are the endpoints of APIs the attacker has access to.

Sadly, almost every business has APIs with some endpoints that are vulnerable to some form of broken object-level authorization. This is not unexpected given the sheer number of possible targets and configurations in the systems we depend on today.

That is why the OWASP named broken object-level authorization the most severe and most common API vulnerability today.

So far, we have mainly focused on addressing broken object-level authorization vulnerabilities in the context of APIs. And the reason is that these attacks primarily target back-ends and APIs accessible to users like mobile back-ends and services.

Examples of Broken Object-Level Authorization Vulnerabilities

Now that we have defined what broken object-level authorization is, let's see some examples.

Mainly, there are two types of BOLA attacks:

Targeting User ID

When we set a vulnerable API endpoint to receive input from the user, an attacker can take advantage of poor implementations to retrieve resources. In this case, the endpoint will receive the provided user ID and try to access the user object.

A simple example of this attack would be something like the following:

bigbank.com/myapi/statements/get_statements_for_user?user_id=666

Targeting Object ID

Following the same pattern, an endpoint that allows user input of objects to retrieve resources allows attackers another avenue to retrieve resources. However, in this case, the input is the object ID itself. The vulnerable API endpoint receives an object ID provided by an authenticated user and tries to access it.

An example of this attack would be the following:

bigbank.com/myapi/transactions/download_pdf?transaction_id=1234

It is pretty clear what kind of trouble would arise if a user accessed our system's transactions by mere guesswork. Therefore, although convenient, you should avoid this kind of practice at all costs.

As I have mentioned before in our NodeJS article on broken object-level authorization, "Many could argue that there are specific cases where data has no sensitive nature. And thus you could forgive the use of simpler, more lenient approaches. However, I would argue that this vulnerability is, in fact, representative of a fundamental gap in the infrastructure and design of any system, and accepting the gap as a feature is shortsighted and dangerous."

Mitigating Broken Object-Level Authorization Vulnerabilities

OK, so how do we address these vulnerabilities, then?

The good news is that the mitigation strategy is simple. However, eradicating the threat might prove quite challenging, depending on the scale of your platform.

First, make sure you have implemented a robust and battle-tested authentication and authorization framework like Devise.

To install Devise, all you have to do is add the gem on your Gemfile.

gem 'devise'

Once you've done this, you need to run the bundle install command to install the gem dependency in your project.

bundle install

Next, run the following command to generate the default resources the gem needs on your project.

$ rails generate devise:install

Now, add the following configuration in your config file to set up the emailing settings for user authentication and confirmation.

config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }

After doing this, run the following command to generate or update the models representing the users in your project. In this case, you can replace MODEL for whatever model name you're using for your users.

$ rails generate devise MODEL

Finally, run the migration command to update the database to reflect the revised model structure.

rails db:migrate

All you need to do now is add the following line on the controllers you want to enforce authentication on.

before_action :authenticate_user!

There are a few more steps that you might need to follow to have your application protected with Devise. Please visit the devise official GitHub page here for more information.

Now, let's see how we can implement the mitigation strategies in our project.

Vulnerable User ID Endpoints

To address this vulnerability, ensure that the user ID in the session object, which resides in current_user.id, matches the user-provided value. If there is no match, then deny access and redirect the user. That's it.

It's important to note that the implementation of this solution could get a bit more complex as you start introducing user roles and hierarchy. However, Devise provides excellent documentation and examples of doing just that on their extensive developer resources.

Vulnerable Object ID Endpoints

Now, this vulnerability might require a bit more work to address, given that multiple users might have access to resources, and there's an inherent complexity level in user hierarchy involved. However, the logic to address this issue is still the same.

Once you have identified a vulnerable endpoint, you can confirm that the user has access to this object by including it in the query string that retrieves it.

One example would be the following:

Statements.where({ id: params[:id], user_id: current_user.id })

This example assumes that the Statements table has a user_id column or that the Statements model has already defined the table relationship with it properly.

Final Thoughts

Unfortunately, rails broken object-level authorization vulnerabilities exist mainly due to poor implementation of authorization mechanisms and human error. Additionally, many development teams consider that some endpoints don't need strict authorization mechanisms. This is because they lack sensitive data in use. Given that the web comprises APIs that handle sensitive and non-sensitive data, it is easy to assume that some requests should have authorization checks and others shouldn't; therefore, it's easy to dismiss a check when writing your code.

Nevertheless, keep in mind that it is your responsibility to protect the data of your users by providing robust and secure platforms.

NodeJS Broken Object Level Authorization Guide: Examples and Prevention

StackHawk

Keeping our systems secured and robust can be challenging when facing so many threats on a daily basis. One such threat, called broken object-level authorization, was referred to as the number one threat APIs worldwide face today by the OWASP security organization.

This article aims to give you the knowledge and expertise necessary to mitigate this threat. To achieve that, we will be examining what broken object-level authorization is, how attackers abuse these vulnerabilities, and what we can do about it.

We'll start by defining broken object-level authorization. Then, we will provide examples of the two types of broken object-level authorization attacks. And lastly, we will provide you with mitigation strategies against this threat so you can successfully protect your platforms.

By the end of this article, you'll be able to spot broken object-level authorization vulnerabilities and have the tools and knowledge to handle them.

NOTE: This article is aimed at NodeJS and Javascript developers. If you have no experience working with NodeJS or Javascript, you might struggle to get value from this article.

NodeJS Broken Object-Level Authorization

As described by the OWASP in their 2023 report on API security:

"Attackers can exploit API endpoints that are vulnerable to Broken Object Level Authorization by manipulating the ID of an object that is sent within the request. This may lead to unauthorized access to sensitive data. This issue is extremely common in API-based applications because the server component usually does not fully track the client's state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access."

Now, that is a handful. Don't worry if you can't fully grasp it yet. We will go through the basics to expand on their information.

However, we must understand what authorization is and its nuance before addressing the question.

As we have previously explained in our Rails article:

"In the context of software security, authorization is the mechanism that provides or denies access to resources in a system. Its main job is to ensure that only the people and services authorized to access these resources (data mainly) can do so. This means that without a proper and robust authorization mechanism, all data in a system is at high risk of falling into the wrong hands."

Briefly, authorization systems are the policy enforcement mechanism for your application. They provide the infrastructure to maintain trust in the security of your system and its data.

What Is Broken Object-Level Authorization?

Translating what the OWASP report stated, now we can summarize that broken object-level authorization, or BOLA, is a specific attack that targets weak or poorly implemented authorization mechanisms.

This attack exploits endpoints that allow user input to retrieve objects (data) without proper user authorization validation.

Basically, a bad actor can target your application whenever it doesn't correctly validate that the user requesting a resource has access to it.

Examples of NodeJS Broken Object-Level Authorization

Since we now understand the theory behind BOLA attacks, let's see some examples. There are two types of BOLA attacks that comprise the vast majority of threats:

Attacks That Target Endpoints That Use User ID

In this attack, the attacker focuses on endpoints that receive a form of user ID to retrieve resources. The vulnerable API endpoint will receive the provided user ID and try to access the user object.

One example of an attack would be something as simple as the following:

Of course, this kind of vulnerability is a massive oversight in terms of security. That's why it is imperative to keep an eye on these gaps in security at the development stage.

Attacks That Target Endpoints That Use Object ID

This attack also targets endpoints that receive user input to retrieve resources. However, in this case, the input is the object ID itself. The vulnerable API endpoint receives an object ID provided by an authenticated user and tries to access it.

A good example of this attack would be the following:

Although convenient and easy to implement, you should avoid this kind of practice at all costs, given the potential for exploitation.

Some could reason that there are particular circumstances where data is not sensitive, and you could forgive the use of more simple, lenient methods. However, I would argue that this vulnerability is, in fact, representative of a fundamental gap in the infrastructure and design of any system, and accepting the gap as a feature is shortsighted and dangerous.

Addressing NodeJS Broken Object-Level Authorization

As grim and scary as all this might seem, I have some good news. The mitigation strategies to address these vulnerabilities are pretty simple. However, depending on the scale of your platform, you might need to do a lot of testing.

For brevity's sake, we will provide a simple session-based method to provide an authorization mechanism in NodeJS, but keep in mind that you can use more robust solutions like passport and Auth0.

If you already have an authentication mechanism, you can skip until the last step of this section.

First, make sure you have installed the following packages:

npm install express express-session mongoose connect-mongo

We will use express-session to handle the session creation and MongoDB to store the session in the database.

Next, modify your application code to include the libraries just loaded.

Then, proceed to add a route with the login form if you don't already have one.

Finally, add a middleware that will add the session data to the request header and retrieve it on every request for validation purposes.

Now that we have a way to identify the user, let's implement some mitigation strategies in our project.

Vulnerable User ID Endpoints

To address this vulnerability, ensure that the user ID in the session object, which resides in req.session.userId, matches the user-provided value. If there is no match, then deny access and redirect the user. That's it.

Vulnerable Object ID Endpoints

Addressing this vulnerability works similarly. You need to confirm that the user has access to this object by including it in the query string that retrieves it.

One example would be the following:

Moving Forward

One of the main reasons that broken object-level authorization vulnerabilities are so rampant and ubiquitous is poor authorization mechanisms and human oversights.

However, it is essential to remember that you are responsible for protecting your user data and implementing robust solutions available.

We recommend you consider using our dynamic application security testing (DAST) at StackHawk.

DAST runs security tests against a running application in real time, finding vulnerabilities your team introduced and exploitable open source vulnerabilities like broken object-level authorization.

You can learn more about it here.

Developing with Webhooks

Brandon Ward

A webhook, or event driven web callback, can best be described as a “Reverse API”, meaning that an external third party will provide the API specification / contract, but it is up to you, the consumer, to implement this API. You have probably come across webhooks in action, even without knowing it! If your organization automatically triggers source code builds from commits, chances are your source control is alerting your build system via a webhook! Did you know that StackHawk also provides a webhook? It can programmatically keep you informed on all of your completed scans.

Tools

The webhook provider - this can be a third party such as GitHub, Jenkins, or StackHawk. For this post, we’ll be using StackHawk’s webhook.
ngrok - a networking tool to allow making your local API publicly accessible.
(optional) node - if you aren’t developing your own application (yet), you can use the provided and simple echo.js script which will print out all inbound network requests. Feel free to use your own application framework and API as well!

(Optional) Run the sample application

If you haven’t started writing your own application yet, you can run this simple node js application (in the linked gist) that simply logs all requests. This simple node js application is also useful if you want to inspect the requests being sent by your webhook provider!(save as echo.js):

https://gist.github.com/Bwvolleyball/c6315f3a744d2e3f52fece0cfd121dca

After you’ve saved this file, you can run it locally with this command:

SERVER_PORT=8080 node echo.js

Start ngrok

Next, you’ll want to start ngrok. After you’ve followed ngrok’s configuration instructions, just run ngrok http 8080 (or whatever port your application is running on locally).

You’ll notice that this command details a few forwarding entries, we’re most interested in the https URL it creates for us, as many webhook providers (StackHawk included) require an SSL secured connection.

Configure Webhook Details

If you are following along with StackHawk, you’ll provide this URL to the StackHawk webhook configuration (or another webhook provider such as GitHub).

If you are using the supplied echo.js script, the values for authorization can be anything you’d like, or nothing at all. If you’re developing your own application, this value should be equivalent to how you expect StackHawk to authenticate with you.

Activate the Webhook!

Perform an operation that causes a webhook event!

The StackHawk webhook emits an event with each successful scan. Check out our docs to run your own scan, scan one of our sample applications, or read more about our webhook.

If you’re using something else like GitHub, push a commit to your repository!

If you are running the example node js application, you’ll see that it has logged the request from your webhook event.

And that’s it! Now you have all the tools you need to start quickly developing with webhooks!

Laravel Broken Object Level Authorization Guide: Examples and Prevention

StackHawk

Broken object level authorization (BOLA) is a common website vulnerability. It happens when a web application or API fails to check user entitlements properly. As a result, attackers can access sensitive website data with little or no website permissions, leading to serious security breaches. All web developers need to be aware of BOLA and how to prevent it.

This article will look at examples of broken object level authorization (BOLA) problems in Laravel applications and how you can fix and prevent them.

Broken Object Level Authorization

When object level authorization works, it checks a user's entitlements before allowing them to access information. We call it "object-level" because applications have to perform this kind of authorization on individual objects, as clients request them.

Responsibility for object level authorization falls to application code. Third-party services and libraries work for authentication, and they may be able to provide applications with information about users after identifying them. But applications need to verify access to specific objects.

Therefore, BOLA is when an application doesn't verify access or fails to do it properly. This means that users can read, delete, create, or update data they shouldn't be allowed to.

BOLA problems are easy to exploit.

Many attacks are waged with a simple shell script, so attackers take advantage of as soon as they're detected. Also, because of the nature of the issues, it's easy to steal large amounts of data.

Let's look at an example to see why.

Broken Object Level Authorization in a REST API

A Simple API

Let's design a REST API for managing comic books.

The API represents Comics with JSON objects that look like this:

{ "id":"1", "publisher": "DC Comics", "title":"Action Comics", "issue":"100", "price": "$10000" "count": "10", }

The API has endpoints for managing comic book records.

POST /comics/ with a JSON record to add a new comic to inventory.
GET /comics/{ID} to retrieve a book by Id.
GET /comics/ with no argument retrieves a list of all comics
PUT /comics/{ID} with a JSON record updates an existing comic with new information.
DELETE /comics/{ID} deletes a comic

The BOLA Problem

In a typical inventory system, different users have different levels of access.

Store managers can add new comics, change their inventory level, and delete comics from the database.
Salespeople can retrieve books and adjust inventory levels when they sell a book.
Customers can retrieve information about comics.

If you know a comic book's Id, you can retrieve, update, or delete it. If you know to call /comics/ with a GET and no arguments, you get a list of all of the comics in inventory, with their Ids. This might not seem like a big problem, but imagine if this vulnerability existed in a user database.

With this API design, the responsibility for verifying user entitlements falls on the application. It's not good enough to check that a user has a valid session. The application needs to verify the user's name against a list of entitlements.

Laravel Broken Object Level Authorization

Let's look at BOLA in Laravel. We'll use an application that implements the API described above.

A Simple Laravel Rest API

Laravel makes building a CRUD API very straightforward.

Since we're using MySQL as the backend for storing comics, the model code couldn't be simpler.

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory; use Illuminate\Database\Eloquent\Model;

class Comic extends Model { use HasFactory; }

Laravel makes basic authentication easy, too. By wrapping the calls to the controller with calls to Sanctum, it's easy to ensure that no one accesses the API without a valid session.

So, our routing entries for the comics API use the Sanctum middleware. Meanwhile, the login and register routes so you can use them to create sessions.

The comics controller uses the model to retrieve, update, create, and delete items in MySQL.

Finally, we need a controller for creating new users and logging them in.

Testing the Service

So, let's take the new service for a spin.

A new user wants to buy some comics via the web. They try to list a comic via the API.

The GUI shouldn't let you get to this point, but since the API blocks unauthorized requests, no harm done.

This simple service is returning an Internal Server Error because we haven't wired all the proper statuses together yet. In production, you'd get a 401 instead of 500.

So, our new customer gets on the right path and creates a new login.

Now they have a login and a token, so they can look at comics!

The simple authorization we set up expects the token to be returned as a Bearer Token.

Success!

In a shopping app listing all items isn't an issue, especially of the API knows how to implement pagination to keep from blowing up your UI. But in an application that manages user data, this would be a problem.

Anyway, that Hulk comic looks expensive, and the title's wrong, too! Let's fix that.

Here's the update to the record:

Here's the PUT request. We're going to try to update a comic using a customer's bearer token.

The request succeeded. The server returned a 200 and echoed back the new value to us.

Let's double-check.

Uh-oh. We changed the inventory using a client's credentials. That's broken object level authorization.

Fixing Laravel BOLA

So how do we fix this?

We need to verify that users are entitled to make a request, not just that they have a valid session.

Laravel makes this easy. When Sanctum verifies the bearer token, it adds the user information to the auth object that's associated with the request. So, we can check the user name before processing the request. It's stored in auth('sanctum')->user().

Let's allow the sales to update comics so they can adjust the quantity when they sell one, and we'll allow the boss because they're the boss. If the user isn't one of these people, we'll return a 401.

Let's test this with the new user's bearer token.

We got a 401 (Unauthorized) status back. It works!

Hardcoding values like user names is never a good idea. Ideally, we'd add this to the database schema, but we can add it to the configuration file for now.

So, let's add two arrays to the application configuration in config/app.php:

'administrators' => ['theboss'], 'sales' => ['sales'],

Now we can have more than one administrator or sales account.

Next, update the check to use the configuration values:

Before updating an item, the function checks the user name against both arrays. It only allows the request to pass if the requestor is a member of administrator or sales.

We can restrict deleting items to administrator now, too:

So, this app has simple object level authorization now. A better solution might ut the access levels in MySQL and maybe even return them as part of the Sanctum information. But, the major security hole is fixed, and the entitled users aren't hardcoded.

Wrapping up

We started by looking at broken object level authorization and how users can exploit it to steal or alter information they shouldn't have be able to. Then, we moved on to Laravel broken object authorization in a simple REST API. We saw how the vulnerability looks and applied a simple fix.

Now that you know how to address BOLA, you can build safer and better applications. But if you want to upgrade your security skills, StackHawk has the tools you need. Sign up for a free account and see how!

Lua CSRF Protection Guide: Examples and How to Enable

StackHawk

It's hard to imagine the world without the web. It was a world where we had to conduct most of our business in person! It was a world where we had to mail checks to pay our bills and visit banks to deposit and withdraw money. Now we can do almost everything online, and sending a check seems unthinkable when we simply pay a bill or complete a purchase with a tap on a screen or click a mouse.

But that convenience doesn't come without significant risk. Users have to ask if they should tap on that button and you, the developer, have to make sure your buttons are safe. Are you protecting your users from Cross-site request forgery (CSRF)?

CSRF is a type of attack where a hacker figures out how to get a user to execute a dangerous web query. This attack is also known as XSRF, Session Riding, Hostile Linking, and several other names.

Let's talk about CSRF attacks and how you can protect your Lua web applications from them.

What Is CSRF?

An attacker uses cross-site request forgery when they harness a user's entitlements over a web session to submit a malicious request. The attacker can work around the usual security limitations by deceiving the user into sending a forged query like a POST, PUT or GET that deletes or steals data or even submits a dangerous funds transfer.

Like many of the most effective attacks, CSRF often relies on social engineering. These hacks only work when a user clicks on a dangerous link. One effective way to make that happen is to trick a user into clicking on a link in an email or a chat.

These links trigger damaging transactions on a vulnerable site if the user has a session open. So, for example, if a link in an email points to a website that the user has already logged in to, the attack will take advantage of a valid session cookie.

These attacks are depressingly common. Websites can't protect themselves from social engineering, so developers are left to figure out how to blunt CSRF hacks without sacrificing user convenience and satisfaction.

So, it's crucial that you ensure that you protect your web application from CSRF attacks.

CSRF Attacks

Let's look at two examples of CSRF attacks. Then we'll see how you can protect your Lua web code from them.

Please Confirm

Here's an example of an HTML email.

This is a barebones example, but imagine a hacker sending this email with branding lifted from a well-known payment service. (We don't want to do that here for obvious reasons.) The attacker has purchased an email list and generates and sends a message for each email. They're gambling that at least a few targets will have an open session with the service and aren't paying close attention.

Let's look at the link.

Rather than confirming a transaction, this link initiates a transfer to someone else! The link sends a GET request with parameters that send a lot of money to a user named techbro.

How can a user protect themselves from this attack? They can pay attention to when and why their bank and payment services send emails and what they look like. They can read emails closely and look for incorrect branding and awkward grammar. They might look at links before clicking on them if they're really savvy.

But most users don't do these things, and it only takes one for an attack to succeed.

It's up to developers to make sure that an attack like this doesn't work. Let's look at one more before we talk about solutions.

Bad Form

The previous example needed a user to click on a link to work. When they did, it sent a rogue GET request to the bank. What if the email had an embedded form instead?

Here's the source for a new version of the email attack.

The email looks exactly the same, but instead of waiting for the user to click on a link, it sends a POST request as soon as the HTML renders! For good measure, the link has an attack, too. A similar threat might attach the confirmation link to a form with hidden values instead of concealing it. There are many ways to fashion an attack using HTML mail and HTML chat messages.

These examples are rudimentary and, as mentioned above, not formatted like more sophisticated phishing attacks. But it's not hard to imagine attacks with "trade dress" stolen from popular banking and shopping websites.

So, how do we protect our users?

Lua CSRF Protection

The most common approach to protecting a web application from CSRF attacks is generating a token and returning it to users in page responses. If subsequent requests don't include the token, the application knows that the request is unsafe.

There are three approaches you can take with CSRF tokens.

Synchronized tokens are unique for each client session. This means that the server has to maintain state information for each session, collate CSRF tokens with them, and dispose of tokens when sessions are destroyed or expire.
Encrypted tokens are shared across all clients. These tokens contain a value that the application encrypts with a private key so only they can verify that the token is legitimate.
Origin headers put the CSRF token in a header that the server expects to see echoed back on requests.

So how can you use these techniques with Lua applications?

Write Your Own

You can write code to generate a token, embed it in pages, and ensure that it's echoed back to your application when you require it. This requires extra work and extensive testing, but it gives you complete control over the solution. Lua has tools for adding tokens to web pages or writing headers, so you can pick your approach.

This GitHub Gist has sample code for a solution that runs in Nginx's Lua module.

Nginx Lua

If you're running Nginx's Lua module or the OpenResty web platform, you can use Nginx's web application firewall. It has many features to protect your applications from attacks, including CSRF. Nginx generates an origin header that acts as a CSRF token. You can configure Nginx to require this header for specific URLs, such as POST, PUT and DELETE actions.

Or, you can use the gist linked above.

Apache Lua

Apache doesn't have any built features for CSRF protection. There are a few third-party modules, but they are older and don't appear to be actively supported. If you're using Apache, you'll need to write your own code.

Lapis

Lapis has built-in CSRF protection features. It will generate a shared cryptographic token and check for it on web requests.

Protecting Your Web Applications

This post looked at what CSRF attacks are and the danger they present to you and your web users. We examined a pair of examples. Both examples demonstrated how dangerous fraudulent emails are and how easy it is to wage a CSRF attack against an unprotected application. Then we looked at typical protections against a CSRF attack and how you can either code your own or take advantage of CSRF protection from Nginx and Lapis. Unfortunately, Apache applications have to risk a third-party module or code their own CSRF tokens.

Cross-site request forgeries are dangerous attacks, but you can protect your applications from them with well-documented tools and processes. While you're taking a close look at application security, check out StackHawk and see how it can help protect your users from attacks like CSRF! There's a free plan with unlimited scans that you can try today!

.NET Broken Authentication Guide: Examples and Prevention

StackHawk

In this article, we'll address broken authentication, explore the intricacies of authentication, and show you how to provide appropriate security mechanisms for your website.

First, I'll briefly discuss what broken authentication is. Then I'll use examples to illustrate what broken authentication attacks look like and which vulnerabilities they target. Finally, I'll offer some mitigating strategies to address those vulnerabilities.

But before getting started, I want to clarify that this article is for .NET developers. With that out of the way, let's jump right in.

What Is Broken Authentication?

"Broken authentication" is an umbrella term that describes several vulnerabilities that attackers can exploit to hijack your system and impersonate users.

An authentication mechanism ensures that only a verified user can access information and privileges on a web application. However, it's "broken" when an attacker successfully bypasses the process and impersonates the user. Essentially, the attacker skips the login security and gains access to the privileges the hacked user has.

These vulnerabilities go hand-in-hand with poor session management and credential management. Attackers can disguise themselves as a user by hijacking a session ID or stealing login credentials. This kind of breach enables attackers to compromise passwords, keys or session tokens, user account information, and other details to assume user identities.

How Broken Authentication Happens

Let's look at exactly how attackers can hijack your system.

Broken Authentication Through Poor Credential Management

Given a poor implementation of credential management, an attacker can hijack your authentication mechanism to gain access to the system.

There are various ways poor credential management allows attackers to achieve this. One is by allowing weak passwords like "12345" or "password." When your system allows users to create weak passwords, an attacker can use password-cracking techniques like brute force, rainbow tables, and dictionaries.

Another way you might be allowing attackers to wreak havoc on your security is by using weak cryptography. When your system uses inadequate encryption mechanisms like base64 and hashing algorithms like SHA1 or MD5, your user credentials will be exposed during a breach.

Broken Authentication Through Poor Session Management

Whenever users interact with your website, your application issues session IDs and records their interactions. As stated by the OWASP broken authentication recommendations, this session ID is equivalent to your original login credentials. So, if an attacker were to steal your session ID, he can essentially impersonate your identity.

This kind of breach is called session hijacking.

Examples of Broken Authentication

Below are some examples of broken authentication attacks in detail.

Password Spraying

The term "password spraying" refers to the use of simple and weak passwords, such as "12345" or "password," by attackers attempting to breach secure accounts.

Credential Stuffing

Whenever a breach happens on a system with a large user base with improperly encrypted credentials, users are vulnerable to credential stuffing.

Credential stuffing is the use of credentials obtained from other breaches. This approach assumes that a significant number of users will probably be using stolen credentials on different platforms.

Session Hijacking

You make your users susceptible to hijacking and impersonation when using session IDs. For example, suppose a user forgets to log off. In that case, any other person can hijack their session and act like the victim on your system. Additionally, if the same ID is issued before and after authentication, it could potentially open the door to an attack called session fixation.

Session ID URL

If your system implements session ID by appending it to the URL, any individual who can gain access to that URL can impersonate the user's identity. Attackers can do this by hijacking insecure Wi-Fi connections, man in the middle attacks, or simple eavesdropping at the address bar.

Phishing Attacks

Finally, users can be susceptible to phishing attacks that send links to websites that look legitimate, convincing them to cede their login credentials. This last attack is quite notorious and challenging to address as it relies squarely on the user's capacity to spot them.

Addressing Broken Authentication Vulnerabilities

In order to address the vulnerabilities above, you need to follow best practices from the Open Web Application Security Project, or OWASP. Thankfully, you can activate most of these recommendations in ASP.NET Core using the configuration file in your project.

Secure Password Storage

You must encrypt, hash, and salt all passwords. This protects users in case of a breach and slows down brute-force attacks and other malicious attempts. Thankfully, if you're using the ASP.NET Core Identity framework, you already have secure password hashes and a unique salt mechanism implemented. ASP.NET Core Identity uses the PBKDF2 hashing function for passwords, and it generates a random salt per user.

Don't Allow Weak Passwords

You must require all users to fulfill specific requirements when specifying their passwords. For example, setting passwords to a particular length and requiring special characters and letters as well as numbers helps prevent credential theft. Consequently, your system will reject passwords that don't meet the requirements.

You can do this by modifying the IdentityOptions method like so:

Keep in mind that some of these specifications protect users better than others, but they might also do the opposite if users won't comply with them.

Add a Strict Credential Recovery Process

I recommend that you implement a strict process for credential recovery. This should involve several verification checks and steps that make it hard and costly for attackers to abuse.

You can achieve this by adding the following lines to the previous code:

Implement Breached Password Protection

A breached password protection mechanism will lock the accounts of users whose passwords have been compromised. In addition, you can configure this mechanism to return access when users change their passwords. This way, you guarantee that the users have a chance to prevent damage if attackers steal their passwords.

You can implement this using a Git project called PwnedPassword that will provide an updated repository of breached passwords to cross-validate in real time.

Regulate Session Length

All web applications must end user sessions after a certain period of inactivity. The length of this period depends on the type of application. For example, a streaming platform might require a long period of inactivity, while a sensitive banking website should have a short time limit.

To regulate the length of a session, add the following lines to the project config file.

Improve Session Management

It's imperative that your platform provides individual session IDs after every successful authentication attempt. In addition, your system must invalidate old session IDs to prevent hijacking as soon as a session ends.

Don't Use Session ID URLs

In all cases, you must secure web URLs with SSL without including the session ID.

Multifactor Authentication

Multifactor authentication (MFA) is one of the most robust protection mechanisms at your disposal. MFA requires an additional credential to verify a user's identity. An example would be a one-time password (OTP) mailed or messaged to the user.

Phishing

It's vital to provide regular education for users about the potential risks of phishing attacks and weak passwords. Sending monthly or quarterly emails reminding users to be vigilant and cautious will usually suffice.

Conclusion

It's your job to implement robust and comprehensive security measures to ensure the safety of your assets and the data of your users. However, it's challenging to keep up with the ever-evolving threats on the web. That's why we recommend Dynamic Application Security Testing (DAST) from StackHawk. DAST runs security tests against a running application in real time, finding vulnerabilities your team introduced as well as exploitable open-source vulnerabilities like broken authentication.

Golang Broken Authentication Guide: Examples and Prevention

StackHawk

Security is important in the software industry. With appropriate security, you can prevent information theft and other cybercrimes. One important aspect of security is to verify the identity of all entities so that intruders can’t get access into the application.

This is exactly what authentication is all about. It ensures users can't access information stored in the application until they can prove that they're who they claim to be. In this article, we'll explain authentication, how to prevent broken authentication, and go over some examples of broken authentication in software, and in particular, in applications built with Golang.

What is Authentication?

Authentication is the process of verifying the identity of a user. When a user tries to access information in an application, they have to prove that they're truly who they claim to be. This is important because, most information stored in an application's database is sensitive, such as users’ personal data.

Therefore, you must prevent intruders from getting hold of sensitive information. Users get access to general information in the application without needing to verify their identity. However, they must provide a means to verify their identity when they try to access sensitive information. For example, when a user tries to access their personal dashboard, they'll need to provide login details like a username, pin, or password.

We shouldn't confuse authentication with identification, as they're different things. With authentication we want to verify that a user is who they claim to be. In contrast, identification simply asks who the user claims to be. For instance, when a user provides their username, the system checks if the user entered a valid username. However, the system then authenticates the user by matching the username and the password the user provides to ascertain the user actually owns the identity.

What could go wrong if authentication is not properly done? Let's discuss broken authentication in applications and in software built with Golang.

What Is Broken Authentication?

If developers don't implement authentication properly, intruders can get access to the application. This way, they can manipulate the system and pose as different users.

Broken authentication involves exploiting vulnerabilities in an application in order to pose as another user. Here, the intruder acts as a user access the user’s privileges and attack additional users.

Broken Authentication in Golang

Golang is a statically typed programming language mainly used for building microservices and the backend of applications. Like in most applications, authentication is done by the backend of Golang applications, and the frontend handles validation.

In the sections that follow, we'll explore examples of broken authentication in Golang, how to prevent them, and the how broken authentication effects Golang applications.

Examples of Broken Authentication in Golang

First, let’s explore some different types of broken authentication vulnerabilities in Golang applications.

Session ID Vulnerability

We Can also call this type of vulnerability session fixation. According to OWASP, (Open Web Application Security Project), this vulnerability allows an attacker to get a valid session ID, manipulate a user to authenticate themself with the session ID, and hijack the validated session with the knowledge they’ve gained of the session ID.

This type of attack is only possible because the system doesn't assign a new session ID when authenticating users. Therefore, the attacker can use the existing session ID.

An example of session ID attack involves an attacker sending a link with a session ID a user. The user then provides their login details for authentication. Because the attacker already made a connection to the application's server, the server doesn't create a new session ID, allowing the attacker to pose as the user. Attackers can also exploit session ID by implementing client side scripting.

Predictable Login Details

We can also call this type of vulnerability password spraying. This is a type of brute force attack where the intruder quickly tries to guess a user's password.

If the user makes use of a simple and predictable password, an intruder can guess their password easily. The attacker repeatedly tries to guess a user’s password, then moves to another user if they don't succeed.

Unprotected Login Details

To avoid attacks or exploitation of an application's database, software developers encrypt login details before storing them. This way, if an attacker gets hold of the database, they can't decipher user login details.

Applications that don't encrypt login details are vulnerable to attack. If an attacker gets hold of the application's database, they can easily log on to any user’s account. Attackers can also exploit login details of users if they're sent over to an application unencrypted.

Session Hijacking

Session hijacking is a type of attack that occurs when an attacker takes over a user's web session after the user successfully logs into their account. To accomplish this, the intruder compromises session tokens.

Session tokens are encrypted strings that differentiate user connections to servers. When an attacker can predict session tokens, or log on using stolen tokens, they can access user accounts.

We shouldn't mistake session hijacking for session fixation. In session hijacking, an attacker hijacks a user session after the user logs in. In session fixation, the attacker launches an attack before the user logs in by tricking them into clicking on a stolen session ID.

Rainbow Table Attacks

Although software developers take the extra step of encrypting user login details, they're not safe from attackers. This is because attackers can exploit an application's database if the database is exposed. Attackers can decipher password hashes using the rainbow table method.

A rainbow table is a table of reversed hashes. An attacker who has a rainbow table can collect password hashes and decode them using the table.

Prevention of Broken Authentication

In this section, we'll explore the methods to prevent the different broken authentication vulnerabilities described above.

Session Timeout

A session timeout is an event that can cause a session to expire. When a session expires, the ID becomes invalid and the user needs to present their credentials for authentication again.

Developers can implement a session timeout programmatically so that users can't continue with an existing session after some designated length of inactivity. This prevents intruders from reusing an existing session ID. Developers can implement a session timeout in HTTP clients by specifying timeout in http.Client.

var httpClient = &http.Client{ Timeout: time.Second * 10, }

Locking Accounts

Locking an account after a number of unsuccessful authentications is a broken authentication prevention method. Since a brute force attack involves an intruder repeatedly guessing a user's password many times, locking accounts can stop an intruder from accessing a user account.

Another method is to lock authentication attempts from device cookies. This way, attackers can't access user's information by manipulating cookies. Developers can also require users to provide stronger passwords during registration. Using a CAPTCHA can also reduce brute force attacks, since brute force attacks are mostly executed by computer programs, which can’t successfully evade a CAPTCHA.

Adding Salt to Hashes

Incorporating salt into hashes adds extra security to an application. Salts add a unique string of characters to passwords before hashing. This prevents attackers who use the rainbow table method from deciphering passwords. For instance, developers can add random salt to password hashes using Golang's bcrypt. An example of how to use bcrypt is shown below:

Conclusion

Implementing authentication is an important aspect of software development. For this reason, IT firms hire security experts to keep make sure their products have secure authentication.

Although implementing authentication and eradicating vulnerabilities may seem like a lot of work, software tools can make it seamless. For instance, with tools like StackHawk, developers can easily monitor and fix vulnerabilities that attackers can exploit.

This post was written by Ukpai Ugochi. Ukpai is a full stack JavaScript developer (MEVN), and she contributes to FOSS in her free time. She loves to share knowledge about her transition from marine engineering to software development to encourage people who love software development and don't know where to begin.

Rails Broken Authentication Guide: Examples and Prevention

StackHawk

In terms of cybersecurity, authentication and authorization are two of our platforms' most significant security aspects. But, as we know, protecting our applications and our users' data is a battle of many fronts. No doors should be left unprotected.

Nevertheless, you'll spend most of your time and effort securing your website's main avenue of access. That's why understanding a subject like broken authentication is critical to offering a robust level of protection.

This article aims to explore the subject of broken authentication in the context of Ruby on Rails.

We'll briefly examine the concepts of authentication and help you get a good grasp on providing suitable security.

To achieve this, we'll first learn what broken authentication is. Then, we'll use some simple examples to help us characterize what a broken authentication attack might look like in the wild and what vulnerabilities it targets.

Finally, we'll provide you with some mitigating strategies to help you address the vulnerabilities that you might find.

Alright, let's jump right in.

Defining Broken Authentication

First, let's define what the term broken authentication means.

In simple terms, broken authentication is an umbrella used for several vulnerabilities that attackers can exploit to hijack our systems and impersonate other users.

We know that the job of an authentication mechanism in our platform is to ensure that only a verified user can access the information and privileges on the web application. However, it's called "broken" when an attacker successfully bypasses the process and impersonates the user on the application. Essentially, this attacker can skip the login security and gain access to all the privileges the hacked user owns.

To be more specific, broken authentication refers to the vulnerabilities or weaknesses inherent in an online platform or application's authentication mechanisms. We can usually find these vulnerabilities in poor session management and credential management.

Both of these are classified as broken authentication because attackers can disguise themselves as users, either by hijacking a session ID or stealing the login credentials. In addition, this breach enables attackers to compromise passwords, keys or session tokens, user account information, and other details to assume user identities.

Broken Authentication in Action

So, we know that authentication attacks mainly target our credential or session management. But, how does this actually happen?

Well, there are many ways, really. But for the purpose of brevity, we'll be exploring the cases where you implement poor management mechanisms and policies.

Credential Management

Implementing poor credential management mechanisms and policies is a potential avenue for attackers to gain access to your systems.

Security policies that allow the use of weak passwords like "12345" or "password" are one way to weaken our credential management's security.

In such a case, an attacker only needs simple password-cracking techniques like brute force, rainbow tables, dictionaries, and enough time to breach your security and access your system.

Additionally, the use of weak cryptography to secure your users' credentials is a significant loophole in your entire security strategy.

The use of inadequate encryption mechanisms like base64 and hashing algorithms like SHA1 or MD5 provide little to no protection in a database breach, exposing credentials and sensitive data.

Session Management

As we know, whenever a user interacts with your website, the server application provides them with a session ID for session management and records their interactions.

As stated by the OWASP broken authentication recommendations, this session ID is equivalent to your original login credentials. So, if a bad actor were to gain access to this session ID, they can effectively impersonate you and bypass all security mechanisms.

This security breach is known as session hijacking and has devastating consequences for the victim.

Examples of Broken Authentication

Now that we understand how broken authentication happens on our system, let's explore some examples of attacks that target specific vulnerabilities.

Password Spraying

The password spraying attack exploits systems that allow simple and weak passwords, such as "12345" or "password," by its users.

Attackers can use rainbow tables or dictionaries to try as many known passwords on user accounts to fish for weak credentials and gain access to the system.

Credential Stuffing

Credential stuffing refers to the use of credentials obtained from other breaches to gain access to our platforms.

This attack works on the assumption that a significant number of users reuse credentials between platforms due to convenience and friction.

Session Hijacking

As explained above, session hijacking happens when a bad actor takes over a user's session. This can be as simple as a user forgetting to log off from his computer before leaving and someone else taking his place.

Additionally, suppose the same ID is issued independently of authentication status. In that case, it could potentially open the door to an attack called session fixation, where an unauthorized session uses the session ID.

Session ID URL

Attackers can use unsecured WiFi access points, man in the middle attacks, or simple eavesdropping at the address bar to get the user session ID if it's in plain sight.

Mitigating Broken Authentication Vulnerabilities

The best way to address the vulnerabilities and mitigate the risks of breaches is by following the best practices from the OWASP.

Luckily for you, if you use robust and battle-tested gems like devise, you can easily protect your platform from these vulnerabilities.

To install devise, all you have to do is add the gem on your Gemfile.

gem 'devise'

Once you've done this, you need to run the bundle install command to install the gem dependency in your project.

bundle install

Next, run the following command to generate the default resources the gem needs on your project.

$ rails generate devise:install

Now, add the following configuration in your config file to set up the emailing settings for user authentication and confirmation.

config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }

After doing this, run the following command to generate or update the models representing the users in your project. In this case, you can replace MODEL for whatever model name you're using for your users.

$ rails generate devise MODEL

Finally, run the migration command to update the database to reflect the revised model structure.

rails db:migrate

All you need to do now is add the following line on the controllers you want to enforce authentication on, and that's pretty much it.

before_action :authenticate_user!

There are a few more steps that you might need to follow to have your application locked and loaded with devise. Please visit the devise official GitHub page here for more information.

Now, let's see how we can implement the mitigation strategies in our project.

Secure Password Storage

Best practices tell us to make sure that all passwords are not only encrypted but also hashed and salted. This policy safeguards the users' credentials in case of a breach by preventing or at least slowing down any attempts to access breached databases.

If you're using devise, you have encryption and salting active by default.

You can configure the encryption key by modifying the config.pepper value on the devise_initializer.rb file.

Don't Allow Weak Passwords

A secure application must require its users to fulfill specific requirements when creating passwords.

Some of the most common requirements are

requiring passwords to be of a particular length, and
requiring special characters as well as numbers.

These requirements must be first enforced and validated by policies created on the client side by JavaScript. However, you also have the option of validating the values provided on the server side with devise.

You can configure the password length on the devise_initializer.rb file with the config.password_length setting.

Additionally, to validate the password complexity, you can use the following method on your user model:

Keep in mind that some of these specifications are more competent than others in terms of protecting the user, but they might also cause the opposite effect when users might not want to comply with them.

Add a Strict Credential Recovery Process

The credential recovery process should require several validation checks that make it complicated and expensive for attackers to abuse it.

To achieve this in devise, you can make use of the following configuration settings in the devise_initializer.rb file:

config.unlock_strategy
config.lock_strategy
config.unlock_keys
config.maximum_attempts
config.reset_password_within

Implement Breached Password Protection

Implementing a breached password protection mechanism allows your system to lock the accounts of users whose passwords have been identified as compromised. This way, you ensure that users have a window to prevent breaches if bad actors steal their credentials.

To provide this security feature, we recommend Pwned, which provides an updated repository of breached passwords to cross-validate in real time.

Regulate Session Length

Web applications must end a user session after a certain period of inactivity has passed. To regulate the length of the session on your application, just modify the config.timeout_in setting in the devise_initializer.rb file.

Improve Session Management

It's imperative that our platform provides individual session IDs after every successful authentication attempt. In addition, our system must invalidate old session IDs to prevent hijacking as soon as a session ends.

Luckily, devise already takes care of this for us.

Disregard the Use of Session ID URL

Not much of an explainer is needed here. Web URLs must be secured with SSL and not include the session ID.

Conclusion

That concludes our concise exploration of the subject of broken authentication and its complexities. But, keep in mind that it's by no means extensive or complete.

In this article, we took the time to lay out the subject of broken authentication and briefly examined many of the most common and insidious vulnerabilities on the web. Additionally, we provided some approachable and straightforward strategies to mitigate these vulnerabilities.

However, it's our job to enforce robust and extensive security measures to secure our users' data and our clients' assets.

That's why we recommend you consider using our dynamic application security testing at StackHawk.

DAST runs security tests against a running application in real time, finding vulnerabilities your team introduced as well as exploitable open-source vulnerabilities like broken authentication. You can find more about it here.

Lua CORS Guide: What It Is and How to Enable It

StackHawk

Cross-site request forgery (CSRF) is a serious web attack that every developer needs to reckon with. Hackers have used it against web applications to steal valuable user information. Damaging attacks have been found on major sites like ING Direct, Netflix, and YouTube. The best defense is limiting web apps to a single domain, but that's not always wise or possible. You need a way to make cross-domain requests safe. That's where cross-origin resource sharing (CORS) comes in. It's a tool that allows applications to use multiple web and API servers.

Lua is a popular scripting language with many uses, including web applications. So, it's susceptible to CSRF attacks, too. You need to set up Lua CORS?

This post will look at what CORS is, the problems it avoids, and how to implement CORS with a Lua application.

CORS in a Nutshell

Before diving into Lua CORS, let's briefly look at what CORS is.

Cross-origin resource sharing is a security mechanism that defines what an app can request based on its origin—the domain the browser loaded them from. All modern web browsers implement it by default, protecting users from CSRF and similar attacks. Therefore, if you want your application to access more than one domain, you need CORs. The good news is most web infrastructure will handle it for you.

CORS Errors in Action

CORS uses HTTP headers to determine who can interact with your specific destinations. "Out of the box," CORS blocks all requests from a different origin. Imagine a web application with HTML served from a web server at https://example.com:443. In addition, it uses an API server at https://example.com:8083. This is common when an app shares an API between web, desktop, and mobile versions. Without any additional configuration, CORS would block the calls to the API server. So, the web application would fail.

If you opened the browser's web console, you would see an error like this:

Access to XMLHttpRequest at 'https://example.com:8083' from origin 'https://example.com' has been blocked by CORS policy

What happened here? The application made both requests to a server at example.com. Why did the browser deny the second one?

CORS defines an origin with three distinct parts:

Protocol - in this case both were HTTPS
Domain - both were example.com
Port - one was 443 and the other was 8083

According to CORS rules, different ports mean different origins. So, it blocked the request. With no overriding CORS policy in place, modern web browsers default to the same-origin policy; code can only request resources from the origin the browser retrieved it from.

How do you get an application like this to work with CORS?

When CORS Works

Now that we understand what happens without CORS let's talk about what happens when a CORS-enabled browser allows an application to make a cross-origin request. What does the upstream application need to do to make it happen?

As soon as a script makes a request to a different origin, the CORS workflow kicks in. The browser initiates the process with a "preflight" request to the first origin. The request uses the HTTP OPTIONS method and contains details about the request.

The server validates the request and responds with the set of acceptable requests. This response details what is allowed. It contains information about the permitted:

Origins the script can make a request from.
Request methods the script can use with the origins.
Custom headers the script can send to the origins.
Authentication information the script can send to the origins.

Read our detailed CORS guide if you want to learn more about the details behind CORS, including how not to set it up and what a typical attack looks like.

Lua CORS

Lua is a popular scripting language with bindings and implementations for countless different environments. There are a few situations where you need to keep CORS in mind when using it.

When you look at the risks a CSRF attack presents and the power of a language like LUA, which has access to nearly all the C runtime libraries, you might want to code your own CORS library.

Don't.

CORS is part of the HTTP protocol, and you don't want to mix its implementation with your application code. You also don't want to reinvent the wheel, especially when there's already a tried-and-tested wheel available for you to use.

OpenResty

OpenResty is an application server based on Nginx and Lua. It combines the Nginx core with a custom-built just-in-time (Jit) compiler for Lua. So, it's a platform for running extensions inside Nginx, taking advantage of its event model. Since Lua can call C extensions directly, you can use OpenResty to run nearly anything. You can also develop web apps with Lapis, a web framework that runs inside OpenResty.

If you think an application that can do nearly anything sounds like an application that needs extraordinary security protections, you're on the right track. It's almost inevitable that application servers will be subject to CSRF attacks, so you need to protect yourself from them.

The OpenResty project has a CORS library called lua-resty-cors that integrates into the platform and adds configuration options for permitted origins, methods, headers, and other critical CORS settings. It's a backport of a similar filter for Nginx.

If you read a few forum posts and other messages online, you'll see advice telling you to set your permitted domains or origins to * so your application will work. Do not do this. If this were to work, it would open your application to attack. Chances are, it won't work anyway.

If the example.com application were running on OpenResty, we'd configure the platform like this.

This configuration allows code to make requests from any host in the example.com domain, including api.example.com. It explicitly permits the GET, PUT, POST, and DELETE verbs but does not allow scripts to send credentials to cross-origin destinations.

Nginx

If you're only looking to run a few simple scripts or write your own web code, Nginx's lua-nginx-module makes it possible to run Lua scripts in response to events.

Nginx has the ngx_http_cors_filter above, which will implement CORS messaging for you. Its configuration is the same as the OpenResty fork above. There are detailed configuration instructions here, including an example of how not to configure it at the top.

Apache

Apache's mod_lua is an analog to Nginx's Lua plugin. You use it to write Lua scripts that will run inside the server.

Here again, you'll want to configure the webserver for CORS and let it implement the HTTP messaging to you.

If you do a quick search for "apache cors," you'll come across recommendations like this.

<Directory /var/www/html> Order Allow,Deny Allow from all AllowOverride all Header set Access-Control-Allow-Origin "*" </Directory>

This is terrible advice. Line #5 opens a wide security hole in the server, so wide that some browsers may even ignore and reject cross-origin requests.

Instead of opening your server to any request, use a regular expression:

<Directory /var/www/html> Order Allow,Deny Allow from all AllowOverride all SetEnvIf Origin "^http(s)?://(.+\.)?example\.com$" AccessControlAllowOrigin=$0 Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin </Directory>

This is a safer design and emulates the Nginx configuration above.

Wrapping It Up

We've covered what CORS is and how to use it with Lua web applications. Your best bet is to put your code behind Nginx or Apache and let them handle CORS for you. Both web servers have robust CORS support and give you the control you need to serve up powerful applications that are safe and secure.

Now that you know who to safely set up Lua apps, get to work!

.NET XML External Entities Guide: Examples and Prevention

StackHawk

In this article, I will address XML External Entities vulnerabilities in .NET and the potential impact that it can have on your platform. By the end, you can expect to have a basic understanding of XML External Entities, how to find them, and what mitigation strategies are at your disposal to deal with this vulnerability.

We will explore how to implement solutions to XML External Entities attacks on the ASP.NET Core development stack. This means that to get the most out of this article, you need some experience working with C# and ASP.NET. If you are only interested in XML External Entities, we've written a number of articles focused on a variety of technology stacks.

With that out of the way, let's dive in.

XML External Entities

Let's start by explaining what XML External Entities are.

XML, or Extensible Markup Language, is a markup language and file format for storing, transmitting, and reconstructing arbitrary data. In addition, this language is used in the programming world to define rules for encoding documents in a format that is both human-readable and machine-readable.

Alright then, but how can a file structure become a threat to your application?

By default, XML processing tools allow the specification of an external entity, a URI, retrieved and processed during the XML file parsing. This parser can then request and embed the content on the specified URI inside the XML document. And that represents an open door for attacks since an attacker could leverage this property as an avenue to retrieve any resource.

In a nutshell, an XML External Entities attack, or XXE injection, is an attack that takes advantage of XML parsing vulnerabilities. It targets systems that use XML parsing functionalities that face the user and allow an attacker to access files and resources on the server. XXE injection attacks can include disclosing local files containing sensitive data, such as passwords or private user data using file: schemes or relative paths in the system identifier.

Given all this, it should be pretty apparent that any tenacious bad actor could potentially take over your server.

How to Spot XML External Entities

All that sounds pretty concerning. But what does it actually look like?

Let's look at a simple example in action.

Here's a sample XML document containing an item XML element.

<item id="1"> <title>Toilet Paper</title> </item>

Alright, but where's the external entity?

We add external XML entities by using a system identifier within a DOCTYPE header. The purpose of this header is to add a few more properties to the XML file structure.

For example, the code below contains an external XML entity that would try to connect to an internal website. This is not ordinarily accessible for users.

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://myinternalwebsite"> ]> <item id="1"> <title>&xxe;</title> </item>

That is terrible news.

As mentioned before, these entities can access local or remote content on your server. And if you keep sensitive files on the server, those sensitive files will be vulnerable. You could be providing a path that an attacker can use to gain control of your website.

Likewise, other XML External Entities attacks can access local resources that may do even more than return data. This is a common avenue for denial of service attacks.

How to Mitigate XML External Entities Vulnerabilities

With all the definitions out of the way, what can you do to fix this issue on your platform?

I have good news for you. Mitigating XXE injection vulnerabilities is very simple.

Allow me to briefly refer to a previous article on the general approach as a quick refresher.

"Generally, as long as you are not intentionally trying to open a window for the vulnerability and consider that you need the functionality of loading user-provided XML files, you don't have to worry much about this issue."

"Let's illustrate."

"As we have mentioned, if an application has an endpoint that parses XML files, an attacker could send a specially crafted payload to the server and obtain sensitive files. The files the attacker can get depend heavily on how you set up your system and how you implement user permissions."

"So, to prevent this situation from playing out, first, don't use libraries that support entity replacement."

Thankfully, there's no popular library in .NET with such an issue.

Odds are that you are using something like XmlDocument or XmlReader, which both come with protections against such vulnerabilities baked in and the feature of external entities disabled by default.

Below is an example of a default, protected implementation:

public string xml_to_text(xml) { var xml_doc = new XmlDocument(); xml_doc.LoadXml(xml);

return xml_doc.InnerText; }

Now, suppose your application actually requires using external entities for some necessary features. In that case, one approach you can take to minimize the potential for exploits is to safelist known external entities.

Other Strategies

Some other strategies to mitigate XXE Injection attacks include the following:

Use fewer complex data formats like JSON and avoid serialization of sensitive data.
Patch or upgrade all XML processing code and libraries in your application.
Verify that XML file upload validates incoming XML using XSD validation.
Update SOAP to SOAP 1.2 or higher.
Use SAST tools to help detect XXE in source code.

Lastly—and I really want to emphasize this—do not parse XML unless it's an application requirement. There are many ways to offer these functionalities without using these libraries.

And as we have said before, in the end, the best mitigation strategy is to not be open to vulnerabilities in any way.

Moving on

Providing robust and secure services is becoming more and more complicated. Projects of that caliber now require a significant investment of time and extensive expertise. And your organization might not be able to afford that cost.

Now, if you are responsible for a team of competent and productive members focused on delivering speedy and innovative solutions, we recommend our Dynamic Application Security Testing (DAST) suite. Our DAST tool tests a running version of your application to identify potential security vulnerabilities. This will allow you to have real-time, reliable, and detailed reports about the security status of your platform. Our product ensures that you get the best insight and tools to provide reliable decision-making information so that you can go back to focusing on your work.

You can check it out here.

Golang Broken Object Level Authorization Guide: Examples and Prevention

StackHawk

According to the OWASP Top 10 for 2021, the most common vulnerability in web APIs is broken access control. This security issue encompasses several problems, but the largest is broken object level authorization. This problem occurs when an application doesn't properly verify user permissions before providing access to a privileged resource. It's a serious security leak that many applications fail to address.

We're going to look at examples of broken object level authorization (BOLA) issues in golang applications and how you can fix and prevent them.

Broken Object Level Authorization

Object level authorization ensures that users can only access the objects they have the proper entitlements for. While third-party applications and services usually implement authentication, applications need to take care of authorizing access to their internal data. BOLA is when the app fails to do that. Depending on the nature of the problem, it allows users to read, alter, delete, or create data that they shouldn't have access to.

Attackers will quickly exploit a newly discovered BOLA issue in a web API since it's possible with a few simple scripts. So, BOLA means the likelihood of data loss or compromise is very high.

Let's look at an example.

A BOLA Example

Think of a typical Create Read Update Delete (CRUD) API for managing website users.

A user looks like this:

{ "id":"1", "lastname":"Doe", "firstname":"John", "dept":"Janitorial", "email":"jdoe@demo.com" }

It has five endpoints:

POST /users/ with a JSON payload to add a user.
GET /users/{ID} to retrieve a user.
GET /users to retrieve a list of all users.
PUT /users/{ID} updates a user.
DELETE /users/{ID} deletes a user.

This is a standard implementation for a CRUD API. The potential problem is that you can retrieve, update, and delete a user if you know their ID.

If the API only checks if a user is valid and authenticated, but fails to confirm if they should be able to access the user ID, it has a BOLA vulnerability. Worse yet, if you have BOLA and the object IDs are sequential, an attacker can exploit the vulnerability and access all your objects.

Golang Broken Object Level Authorization

Let's look at the above example implemented as a golang web service. We'll see the broken object level authorization in action, and then we'll fix it.

This service uses Gorilla to route API requests, so the main function maps requests to handlers and sets up a listener.

So we can keep our focus on golang broken object level authorization, we'll take a few shortcuts in the example code.

Instead of examing the code to create, verify, and manage a secure user session, we'll use a single mock to confirm that the current session is valid.

Also, instead of looking at SQL or NoSQL code, we'll use mocks to get and set user information.

View a User

So, here's the getUserById handler.

So we can view the BOLA exploit with cURL, we'll use a single header to simulate a valid session.

egoebelbecker@genosha-2 ~ % curl -H "Session_ID: rekcebleboeg" localhost:8080/users/1 {"id":"1","lastname":"Doe","firstname":"John","dept":"","email":"jdoe@demo.com"}

Since this GET handler only verifies that the requesting user has a valid session, anyone capable of creating a session can request a user by Id.

Since we've described this bug twice now, and we're looking at code that calls a method named checkSession(), the bug seems obvious. But that's not always the case, and it's a common design mistake. Many APIs are designed to be shared between a web GUI and a mobile app. The apps implicitly enforce object-level authorization when they lack a GUI element that lets you see someone else's information. Sometimes they're even structured so only one app can perform some functions.

But an attacker will view the web source code and reverse engineer the API, probably in minutes. This API doesn't check for proper access and has sequential user ids. It's in bad shape.

View All Users

So let's imagine that administrative users have a different web interface. They can view all users.

As a result, an attacker doesn't need to use sequential ids to grab the entire user database.

Here's that request. (Some formatting added.)

egoebelbecker@genosha-2 ~ % curl -H "Session_ID: rekcebleboeg" localhost:8080/users [{"id":"1","lastname":"Doe","firstname":"John","dept":"HR","email":"jdoe@demo.com"}, {"id":"2","lastname":"Smith","firstname":"Jane","dept":"Dev","email":"jsmith@demo.com"}, {"id":"3","lastname":"Neuman","firstname":"Alfred E.","dept":"CEO","email":"whatme@worry.com"}, {"id":"4","lastname":"Goebelbecker","firstname":"Eric","dept":"Janitorial","email":"noreply@demo.com"}]

Here again, the application designers were relying on limitations in the client applications to stop users from seeing information they shouldn't.

Fixing Golang BOLA

So how do we fix these problems? There are several different approaches. Let's look at each one in brief.

The Wrong Answer

One answer is to remove the user Id from the API URLs.

So the five endpoints might look like this:

POST /users/ with a JSON payload to add a user.
GET /users/ to retrieve a user with a Header or JSON payload that contains the Id.
GET /users to retrieve a list of all users.
PUT /users/ updates a user.
DELETE /users/ deletes a user with a Header or JSON payload that contains the Id.

This only changes two endpoints and leaves all of the vulnerabilities in place. It might make it harder for an experienced hacker to exploit the API. It probably wouldn't phase a skilled attacker after a few minutes of experimenting with cURL.

There are better solutions.

Add Object Level Authorizations

The best and only effective solution is to add code to verify that users have access to the object they want to create, read, update, or delete.

The sample app already has a method to verify that a session is valid. To observe the single responsibility principle, let's add a new one to check if users can do what they're asking.

There are many ways to do this. Some are better than others, and some fit in a short blog post about BOLA and aren't production code.

First, let's define what a user wants to do and whether or not they can do it. Enums work well for this.

Defining Actions and Authorization

Now, we can write a method that asks if a user can do what they're asking.

This is a bare-bones example of object level authorization. The method allows users to read their information and only allows an admin user to perform other operations. But, since we used an enum for the requested actions, it would be easy to add different levels of entitlements for different actions. So, a department head could modify their team members' records, or a human resources team could add address information, etc.

Adding It to the API

Let's look at the new getUserbyID:

We had to modify checkSession to return a user Id so we could use it to check permissions. If it passes, the method proceeds as before. If not, it returns an error to the requesting application.

Now, getAllusers looks like this:

We don't need to pass a target user to checkAuthorization since we're trying to use the List action.

We'd add checkAuthorization to the other three methods in this app to finish the job, and we have basic object level authorization. Over time it could grow into a more sophisticated example with multiple layers of entitlement instance of a coarse, role-based system.

Extra Credit

While we've patched the big holes in this simple API, we could take one more step to make it a bit more robust: change the user Ids from numerals to a non-sequential format that's harder to guess, like UUIDs. While this doesn't address any security problems in the code, it does make the API a less attractive target.

Wrapping up

We've looked at broken object level authorization and how it exposes APIs to serious security problems. We also looked at an example in golang and how easy a BOLA is to exploit. We addressed the issue with object level authorization code, and then we finished up with another recommendation to help foil simple attacks.

StackHawk has tools to help you find these issues and address them in your code. Sign up for a free account and see how!

Django Broken Authentication Guide: Examples and Prevention

StackHawk

As of 2021, broken authentication is ranked #7 in the Open Web Application Security Project (OWASP) Top 10 list. Authentication system flaws can allow attackers to get access to user accounts and potentially compromise a whole system by utilizing an admin account.

In this post, we'll describe broken authentication. We'll also provide some examples and go through some of the strategies for making Django apps more secure. You should be able to apply what you learn to your Django applications.

Broken Authentication

Broken authentication refers to security breaches that develop as a result of how business applications authenticate users. One of the most commonly abused security-related components of a business system is its authentication systems.

In order to access additional information on most business apps, users must first authenticate their identities using their credentials. A session ID is issued to each logged-in user. This is a type of token that is used to track the activity of logged-in users, comparable to a temporary replacement for the user's original login credentials. Because session information is related to the logged-in user, it's critical to keep track of these session IDs to prevent attackers from impersonating the rightful owner of the session.

Examples

There are various ways in which attackers can gain access through compromised authentication systems.

Exploiting session management issues, such as failing to rotate session IDs after a successful login or failing to correctly invalidate session IDs upon logout
Attempting to brute force legitimate usernames or emails using known passwords
Allowing people to sign up for the site using passwords that are weak or popular, such as "123456"
Using weak credential recovery processes such as knowledge-based answers
Using weakly hashed passwords or plain text passwords

Prevention

Strict Password Policy

It's best to adopt a strict password policy with a minimum length of eight characters and a maximum length of sixty-four characters. Don't allow sequential passwords like "1234" or "asdf", the ever popular "password", or anything related to the organization or email address (if your business name is Stackhawk, for instance, the password should not include "stackhawk").

Using packages like Django-password-strength, you can enforce password checks in Django. Alternatively, you can utilize Django's default settings in the settings.py file, as seen below.

The UserAttributeSimilarityValidator makes sure that the user isn't using passwords that are similar to existing characteristics they have already provided in their user data, such as their name, email address, or role. As a result, an administrative user with the email address "admin@example.com" is unable to use passwords such as "admin", "admin123", "exampleAdmin", and so on.

MinimumLengthValidator in the above code snippet indicates that passwords must be at least eleven characters long. Hence, a user with the given email address "test@example.com" will be unable to sign up with the password "Gracey@me" because the password is only nine characters long.

CommonPasswordValidator prohibits users from using passwords that have been known to be hacked, such as "abcd12345".

NumericPasswordValidator restricts users from solely using numbers in their passwords, such as "0987654321".

In addition to maintaining strong password restrictions, how users log in and out of a business application is equally vital.

Session Management

It's crucial to control how the client or server keeps sessions. Using Django's built-in settings in settings.py, as illustrated below, is one way to manage how long session information lasts.

Django supports settings parameters like SESSION_EXPIRE_AT_ BROWSER_CLOSE and SESSION_COOKIE_AGE to manage sessions. When the browser is closed, the former invalidates the session regardless of how old the session cookie is. The latter invalidates the session only when the session's cookie age is exceeded.

Because SESSION_EXPIRE_AT_BROWSER_CLOSE is set to True, the user may not only log out of the business application but also shut the browser without an attacker accessing the same session data kept in the browser, preventing a session hijacking.

Multifactor Authentication

In business applications, multifactor authentication (MFA) adds an extra layer of protection. Aside from using a username and password, you can utilize additional methods of identification.

There are three types of multifactor authentication:

What a user knows, such as their email address or password
What the user has, such as an SMS token
The user's identity, verified using a fingerprint, iris ID, or facial recognition

Django supports MFA via third-party packages, not as built-in Django packages. Two popular packages for MFA in Django are Django-mfa and Django-multifactor.

During the identification phase, you should avoid employing the same type of multifactor group more than once. If a user joins using their email and password, the second authentication method should be a token or a fingerprint. If the second element of authentication is a fingerprint, the third factor of authentication must be a token.

Vague Responses

It's common for people to forget their sign-up email or password. However, ensuring that any message to the user is vague is critical to prevent malicious users from abusing response loopholes. If, for example, a user tries to log in to a business application with the wrong password, it is typical to respond with a message saying, "The password is incorrect. Please try again." While this may be useful to a genuine user, it's a security hole that an attacker may take advantage of.

Now that the attacker is aware that the email address exists on the platform, he or she can attempt to brute force the account. So instead of providing specific responses during authentication, use vague responses. "Incorrect email or password," for example, would be a typical vague response if a user gets one or the other wrong. A potential attacker would therefore be unsure which is inaccurate.

Furthermore, rather than using alerts like "Email not registered," you might try using a less telling message like "Email sent" for users who try to recover lost passwords. You'll send emails if the email address exists in the application, but nothing will happen otherwise.

Identity Is Everything

In this post, we covered how attackers use session data and weak passwords to exploit authentication flaws. We also showed you how to protect yourself from these attackers by implementing stronger session management and password policies.

Poorly implemented authentication in applications introduces vulnerabilities for attacks. As the world continues to rely on the internet, weak authentication is pervasive, and protecting user identities is more critical than ever.

This post was written by Ifenna Okoye. Ifenna is a software developer with a particular interest in backend technologies including Python and Node.js.