API Security Assurance via E2E Testing

API Security Assurance via E2E Testing

Speakers: Alex Mor, Cyber Security Engineer, AB InBev

Conference: Hacktivity

YouTube: https://www.youtube.com/watch?v=rS2pMxABX5E

Overview

In his Hacktivity talk, "API Security Assurance via E2E Testing," Alex Mor, a Cyber Security Engineer at AB InBev, addressed a critical challenge in modern software development: integrating security testing directly into the developer workflow. Mor posited that API security, often treated as a post-development audit, can be significantly enhanced by shifting left, empowering developers to proactively build security into their applications from the outset. This approach not only streamlines the development lifecycle but also fosters a collaborative environment between security professionals and engineering teams.

The core motivation for Mor's talk stems from the OWASP SAM (Software Assurance Maturity Model) Level 3, which advocates for security testing to be an inherent part of a developer's day-to-day activities, rather than solely relying on penetration testers or automated DAST tools. By embedding security tests within existing end-to-end (E2E) testing frameworks, organizations can achieve continuous security assurance. Mor highlighted that developers typically spend around 50% of their time on testing; allocating an additional 5% to security testing represents a substantial win for overall product security and efficiency.

The presentation targeted a diverse audience, including developers, security engineers, and even ethical hackers, demonstrating how to leverage familiar testing methodologies to create automated, DAST-like security tests. For developers, the goal is to integrate these tests into their continuous integration pipelines, ensuring immediate feedback on security regressions. For attackers, the insights offer a blueprint for creating sophisticated, repeatable tests to uncover vulnerabilities. Ultimately, Mor argued for a fundamental shift in the security-developer dynamic, moving from a report-driven, adversarial relationship to one of partnership, where security professionals equip developers with the tools and knowledge to build intrinsically secure products.

Background

▶ Watch: Motivation: Embedding security testing in developer workflow (2:00)

The landscape of modern software development is dominated by APIs, serving as the backbone for virtually all applications, from mobile frontends to intricate backend services and third-party integrations. This ubiquity, while enabling rapid innovation and scalability, also introduces a vast attack surface. Traditional security approaches, often characterized by periodic penetration tests or static/dynamic analysis tools, frequently lag behind the rapid pace of development, leading to vulnerabilities being discovered late in the cycle, where they are more costly and time-consuming to fix. This reactive posture creates friction between security teams, who deliver lengthy vulnerability reports, and development teams, who are under pressure to deliver features quickly.

Mor emphasized that developers are, in essence, the "keys to the kingdom." They design the architecture, write the code, manage the infrastructure, and build the features that define a product. Without their foundational work, there is nothing for security or quality assurance to test. However, traditional education often falls short in providing developers with adequate secure coding training, leaving them ill-equipped to anticipate and mitigate complex security flaws. This knowledge gap, combined with the inherent trust developers often place in user input, creates ripe conditions for vulnerabilities like those outlined in the OWASP API Top 10.

The talk underscored the importance of integrating security into the existing DevOps paradigm, particularly within the Continuous Integration (CI) phase. In a typical software testing pyramid, unit tests cover individual functions, integration tests verify interactions between components (e.g., application with a database or another API), and system or end-to-end (E2E) tests validate the entire application stack, from frontend to backend and all external dependencies, working as a cohesive system. Mor proposed that security testing should not be a separate silo but rather an extension of these established testing layers, particularly focusing on E2E tests to uncover complex, real-world attack scenarios that span multiple components. This "shift-left" philosophy aims to empower developers to identify and remediate security issues as they write code, drastically reducing the cost and impact of vulnerabilities.

Key Findings

▶ Watch: Emphasizing End-to-End (E2E) testing for application security (9:45)

Alex Mor's presentation unveiled several key findings and insights crucial for modern API security:

1. The Developer's Role in Security: A central finding is the underutilized potential of developers as the primary line of defense. By embedding security testing directly into their development lifecycle, organizations can achieve a higher maturity level (OWASP SAM Level 3), where developers proactively write security tests. This shifts the paradigm from security as a gatekeeper to security as an enabler, fostering a collaborative "gift-giving" relationship rather than a report-driven, adversarial one.
2. Efficiency of Shifting Left: Mor highlighted that developers typically allocate 50% of their time to testing. By integrating security testing into this existing workflow, requiring only an additional 5% investment of their time, organizations can achieve significant security gains. This approach leads to faster vulnerability detection and remediation, drastically reducing the window of opportunity for attackers compared to annual or bi-annual penetration tests.
3. The "Assume All Users Are Attackers" Mindset: A critical insight for developers is the necessity of adopting an attacker's mindset. Mor stressed that a significant portion of traffic hitting applications is malicious (bots, port scans), and developers must build security, including robust input validations, with the assumption that all user input is hostile. This proactive approach helps prevent common vulnerabilities and complex business logic flaws.
4. AI's Potential in Generating Security Tests: A groundbreaking finding demonstrated the capability of Large Language Models (LLMs) like Bard (and by extension, ChatGPT or Claude) to generate sophisticated security test cases for business logic flaws. By providing a well-crafted prompt describing application features (e.g., appointment booking), AI can generate specific, actionable tests targeting authorization bypasses, fraud scenarios, and other complex vulnerabilities that often escape automated tools and require manual effort from security experts. This empowers developers to rapidly generate abuse cases without deep security expertise.
5. API-Centric Vulnerability Focus: Given the prevalence of APIs, the talk emphasized that many critical vulnerabilities, especially those related to the OWASP API Top 10 (e.g., Broken Object Level Authorization, Broken User Authentication, Excessive Data Exposure), can be effectively addressed through automated API-level security tests. By focusing on API endpoints, developers can catch these issues before they manifest in the frontend or impact the broader system.

Technical Deep Dive

▶ Watch: Demo: Identifying and fixing a weak password vulnerability (22:00)

The technical core of Alex Mor's talk revolved around integrating security into established software testing methodologies, particularly end-to-end (E2E) testing and API testing. He contextualized this within the widely accepted testing pyramid, which prioritizes a large base of fast, granular unit tests, followed by a smaller layer of integration tests, and finally, a narrow apex of comprehensive E2E tests. Mor specifically advocated for embedding security checks within the integration and E2E layers, where interactions between different application components and external services can be fully simulated.

For E2E security testing, Mor provided a concrete example: an API endpoint for user creation. An E2E security test would involve creating a user with a malicious payload (e.g., Cross-Site Scripting (XSS) in the first name field) via the API, then using a browser automation tool to navigate to the user's profile page, and finally asserting if any XSS reflections occur. This demonstrates how a single test can span multiple layers of the application stack, mimicking a real-world attack chain.

The talk placed a strong emphasis on API testing due to its central role in modern applications. Mor illustrated how developers, using frameworks like RSpec (Ruby Specification) or similar JavaScript/TypeScript testing frameworks (SuperTest, Cypress, Katalon, Postman), can define clear specifications for API behavior, including security expectations. A basic authentication test, for instance, would describe the authentication functionality and it should successfully sign up a user. This involves sending a POST request to an endpoint with a Data Transfer Object (DTO) containing fields like email, password, firstName, and lastName. The test would then assert for a 201 Created HTTP status code and the presence of a JSON Web Token (JWT) in the response. Mor highlighted the importance of DTOs in preventing Mass Assignment vulnerabilities by explicitly defining which fields an API should accept.

A practical demonstration involved implementing a security test for weak password registration. Initially, a test attempting to register a user with "123456" would pass, receiving a 201 Created status code, indicating a vulnerability. The proposed fix, implemented within a NestJS (Node.js/TypeScript) application, involved adding a validator (e.g., isStrongPassword with a minimumLength: 7) to the user registration DTO. After this change, the same test would correctly fail, returning a 400 Bad Request and a message like "password is not strong enough," thus making the test "green" from a security perspective.

Another technical deep dive showcased the automated implementation of security headers. Mor demonstrated an API response lacking essential headers like Strict Transport Security (HSTS), X-Frame-Options, X-XSS-Protection, Content Security Policy (CSP), and Referrer-Policy. By simply adding the Helmet.js dependency to a Node.js/NestJS application, all these headers were automatically included in subsequent API responses. While acknowledging that some configuration is often required to avoid breaking application functionality, the ease of integration illustrated a significant "shift-left" win, preventing common low-to-medium severity findings in penetration test reports.

Finally, the talk explored the use of Generative AI (specifically Bard, but applicable to ChatGPT and others) to generate complex security test cases. Mor crafted a detailed prompt instructing the AI to act as an application security engineer, focusing on business logic flaws, authorization, and privilege escalation, referencing the OWASP API Top 10, and outputting results in RSpec language. The AI successfully generated tests such as:

• Preventing unauthenticated users from booking appointments.
• Preventing users from booking appointments for other users (a Broken Object Level Authorization (BOLA) or IDOR scenario).
• Preventing users from canceling/modifying appointments they don't own.
• Business logic bypasses like booking appointments for unavailable times or with invalid payment information.
• Preventing multiple appointments for the same time slot or modifying appointments after a deadline (fraud scenarios).

This demonstrated AI's powerful capability to augment a developer's security expertise, helping them identify and test for sophisticated abuse cases without requiring extensive manual threat modeling.

Demo / Proof of Concept

▶ Watch: Practical security headers implementation using Helmet.js (26:00)

Alex Mor's talk was rich with practical demonstrations and proof-of-concept examples, primarily using a hypothetical vulnerable application named Insecure Cutz – a barber shop management system. This application, though intentionally vulnerable for demonstration purposes, highlighted common functionalities like user registration, authentication, profile management, appointment booking, and barber shop profiles, all of which present various security challenges.

The core of the demo involved illustrating how security tests could be integrated into a developer's existing test suite, often expressed in a language similar to RSpec. Mor showed a basic test for user registration, where a POST request sends user data (email, password, first name, last name) to an endpoint, expecting a 201 Created status and a JWT in return. This served as the foundation upon which security-specific tests were built.

A key proof of concept was the weak password registration test. Mor first showed a failing test scenario where an attempt to register with a weak password like "123456" unexpectedly received a 201 Created response, indicating the vulnerability. He then demonstrated how a developer could remediate this by adding a password validator (e.g., isStrongPassword with minimumLength: 7) within the application's NestJS (Node.js/TypeScript) code. After this fix, the same test would correctly yield a 400 Bad Request response, with a message like "password is not strong enough," thus turning the security test "green" and proving the vulnerability was addressed.

Another compelling demo focused on security headers. Mor displayed an initial API response that lacked crucial security headers. He then showed that by simply adding the Helmet.js dependency to a Node.js application, the API automatically started including a comprehensive set of headers, such as Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, Cross-Origin-Opener-Policy, and Referrer-Policy. This illustrated a quick win for developers to implement foundational security controls without extensive manual configuration.

The most innovative proof of concept involved leveraging Generative AI (specifically Google Bard) to create security test cases. Mor presented a meticulously crafted prompt to Bard, asking it to act as an application security engineer and generate at least 10 security tests for an appointment booking feature, focusing on business logic, authorization, and privilege escalation, and referencing the OWASP API Top 10 in RSpec-like language. Bard's output, shown live, successfully generated a range of sophisticated test ideas, including:

• Preventing unauthenticated users from booking.
• Blocking users from booking or canceling appointments for others (demonstrating BOLA or IDOR detection).
• Identifying business logic bypasses such as booking for unavailable times or with invalid payment information.
• Detecting fraud scenarios like booking multiple appointments for the same slot or modifying appointments after a deadline.

This demonstration powerfully showcased AI's capability to assist developers in identifying and articulating complex abuse cases that typically require specialized security expertise, effectively democratizing threat modeling and security test generation.

Defensive Implications

▶ Watch: Q&A: AI's role in property-based testing and fuzzing (38:00)

The defensive implications of Alex Mor's approach to API security assurance are profound, offering a roadmap for organizations to embed security deeply within their development processes. The core message for defenders is to shift left aggressively, empowering developers to become the first line of defense rather than relying solely on late-stage security audits.

Firstly, security teams should prioritize collaboration over confrontation. Instead of delivering lengthy, critical vulnerability reports, security professionals should act as enablers, providing developers with actionable tools, templates, and guidance. This includes creating a "bank of abuse cases" tailored to common application patterns, which developers can readily integrate into their test suites. Mor also suggested offering templates for security tests, making it easier for engineering teams to adopt this practice without extensive security knowledge.

A critical defensive strategy is to instill an "assume all users are attackers" mindset among developers. This paradigm shift encourages the proactive implementation of robust input validation and security controls at every layer of the application. By educating developers on common attack vectors, threat modeling, and abuse cases, security teams can help them build resilience from the ground up, preventing vulnerabilities like SQL injection, Cross-Site Scripting (XSS), and Mass Assignment before they are coded.

Defenders should actively promote the integration of security tests into existing CI/CD pipelines. By leveraging frameworks already familiar to developers (e.g., Cypress, SuperTest, Katalon, JUnit for API and E2E testing), security tests can run continuously with every code commit. This ensures immediate feedback on security regressions, allowing developers to fix issues in minutes or hours rather than weeks or months, significantly reducing the window of vulnerability. The example of validating password complexity and enforcing security headers via tools like Helmet.js demonstrates quick, impactful wins that can be automated.

Furthermore, security professionals should embrace and guide the use of Generative AI as a powerful tool for security test generation. By teaching developers how to craft effective prompts, security teams can leverage AI to identify complex business logic flaws, authorization bypasses, and privilege escalation scenarios that are often missed by traditional automated scanners. This allows for more comprehensive coverage of the OWASP API Top 10 vulnerabilities, which frequently reside in the application's unique business logic. It's crucial, however, to advise developers to use company-owned or private AI instances for sensitive application details to avoid data exposure.

Finally, Mor advocated for upskilling penetration testers and security engineers in programming languages like Python and JavaScript. This enables security professionals to directly contribute to the creation of automated security test harnesses, speak the same language as developers, and effectively integrate their expertise into the development workflow. Measuring the number of security tests versus application tests, and the overall investment in "bulletproofing" the product, provides a quantifiable metric for the effectiveness of these defensive strategies.

Key Takeaways

• Shift Left with Developer-Driven Security: Empower developers to embed security testing directly into their daily workflow, moving beyond reactive, post-development audits to proactive, continuous assurance.
• Leverage Existing E2E & API Testing Frameworks: Integrate security tests within familiar development tools (e.g., RSpec, Cypress, SuperTest) to validate the entire application stack and address OWASP API Top 10 vulnerabilities.
• Adopt an "Assume All Users Are Attackers" Mindset: Developers must build applications with the assumption that all user input is malicious, implementing robust input validation and security controls from the outset.
• Utilize AI for Complex Security Test Generation: Leverage Generative AI (e.g., Bard, ChatGPT) with well-crafted prompts to automatically generate sophisticated test cases for business logic flaws, authorization bypasses, and fraud scenarios, augmenting developer security expertise.
• Prioritize Collaboration and Education: Security teams should act as enablers, providing developers with templates, abuse case banks, and secure coding guidance, fostering a partnership rather than an adversarial relationship.
• Automate Foundational Security Controls: Implement automated tests for common security best practices, such as strong password policies and the enforcement of security headers (e.g., via Helmet.js), to achieve quick, repeatable security wins.

About the Speaker(s)

Alex Mor is a Cyber Security Engineer at AB InBev, the global beer company known for brands like Stella, Corona, Budweiser, and Hoegaarden. Based out of Israel, Alex has been working in cybersecurity for the past four years, specifically focusing on helping e-commerce developers build scalable applications that serve millions of customers. His role involves collaborating closely with engineers, providing guidance and support to secure their products throughout the development lifecycle. Mor is passionate about embedding security into the developer's day-to-day operations, believing that by teaching developers secure coding practices early on, organizations can build more resilient and trustworthy software.