OWASP Global AppSec EU 2026 Vienna

Types in programming languages are meant to protect us, but how often do we still end up chasing silly bugs caused by a single misplaced value? A common culprit is the code smell “Primitive Obsession”: representing everything as integers, strings, and Booleans instead of meaningful domain types. It works until an order ID gets passed where a customer ID was expected, or missing access control is exploited, and nobody notices until it is too late.
Over the last decades, type systems have become surprisingly powerful. Nowadays, even mainstream languages let us encode business rules, workflows, and even security properties directly into types. That means the compiler can act as a very strict, very fast reviewer that never gets tired. It refuses to build your code if a workflow is incomplete, a state is impossible, or an access rule is violated. Entire classes of bugs simply can’t compile anymore. “Security by design” is the core idea behind this presentation.
In this talk, I will show concrete TypeScript examples of how we can model business workflows and constraints with types. Making illegal states unrepresentable, designing internal APIs that are harder to misuse, and capturing security invariants so they’re enforced automatically. The approach is not tied to a single language but is a practical design technique that can make your programming life easier.

People in your organization might have a living-breathing backdoor right now, and you don’t even know it.

EDR wouldn’t catch it - not because it employs a zero-day, but because it behaves harmlessly. It might be a malicious extension that wasn’t flagged yet that has excessive permissions, it might be an NPM package that reads .env files and sends them to a remote server, and it might be an Android application tracking your location.

During our research we detected two seemingly innocent Chrome extensions that add a sidebar with AI capabilities over any website, with a total of 900,000+ users. These extensions had a backdoor that exfiltrated both your browser history and your ChatGPT & DeepSeek conversations - none of them were flagged by anti-malware and EDR tools.

These extensions, together with almost any add-on, NPM package, or application you have installed have broad permissions, giving them the ability to execute code, read files, and basically do anything on your machine.

During our presentation we will present how we dissect a malicious Chrome extension, the techniques that it uses to avoid detection and how it reads and exfiltrates data. We’ll also show how actors think, from cloning legitimate extensions, adding their malicious code and bypassing store reviews in order to publish their malicious extensions into the official Chrome Web Store.

We will present how the permissions model works in different platforms, including the Chrome Web Store, the Android Play Store, and IDE marketplaces - allowing different malware on different platforms to perform bad activities.

Lastly, we will give our insights about how to best protect your personal browser at home and in your organization, to help you reduce the possibility of being infected from malware in official marketplaces. We’ll also discuss how a good permission model should look like, and what companies can do to return the power to the users over their private information in order to protect them from extensions and applications reading their data unknowingly.

The arrival of cryptographically relevant quantum computers (CRQC) is no longer a theoretical "if"—it is a question of "when." With the "Harvest Now, Decrypt Later" (HNDL) attack vector, adversaries are already stockpiling encrypted traffic today to decrypt it once quantum capability matures. In August 2024, NIST officially finalized the first set of Post-Quantum Cryptography (PQC) standards (FIPS 203, 204, and 205), marking the starting gun for the greatest cryptographic migration in history.

This session moves beyond the math of lattices and isogenies to focus on the immediate engineering reality. we will dissect the current state of PQC adoption across major tech giants and nation-states, analyzing how entities like Cloudflare, Google, and the US Federal Government are operationalizing these new algorithms. We will provide a technical primer on the finalized standards—ML-KEM (Kyber), ML-DSA (Dilithium), and SLH-DSA (SPHINCS+)—and expose the hidden performance pitfalls and "gotchas" in implementation.

Attendees will leave with a combat-tested roadmap for enterprise PQC migration. We will cover how to conduct a cryptographic inventory (discovery), the necessity of "hybrid" key exchange (mixing X25519 with Kyber), and how security teams can upskill rapidly. This talk bridges the gap between theoretical cryptography and the practical defense required to secure infrastructure against the quantum threat looming on the horizon.

Kubernetes features are moving fast, and its networking layer is constantly adapting for all new kinds of workloads. However we still lack a basic but essential feature: a way to filter and protect incoming web traffic.

The Gateway API is the natural place to add security, and many enterprises mandate such a thing. In this session, we introduce a new project that connects OWASP Coraza WAF directly with Kubernetes.

Join us to learn more on how Coraza Kubernetes Operator is proposing to bring the well known CoreRuleSet (CRS) filtering approach to Kubernetes, on a structured way, allowing cluster and gateway admins to provide traffic filtering on Gateway API and lift the security features to another level.

The need to isolate untrusted code or user-provided expressions is ubiquitous, even in backend systems, and there are many misconceptions around this practice. Workflow automation platforms allow users to provide complex constraints evaluated on the server, AI agents must securely execute synthesized code, and reused untrusted UI components might render on the server-side. In practice, many developers gravitate toward lightweight eval-based shortcuts instead of robust isolation primitives like OS-level or runtime-based sandboxing, often unaware of the security pitfalls. These dangerous language-features are still very prevalent across OSS ecosystems and they are the culprit of many recent vulnerabilities. While there exist legitimate use cases for eval-like APIs, developers continue to abuse them when attempting to isolate the execution of untrusted code, despite years of warnings from the security and programming language communities. If you really need to use these features, this talk can help you understand what can go wrong and how to mitigate these risks.

I will first motivate the need for lightweight, language-based isolation in scripting languages and highlight the fundamental challenges in this space, grounding the empirical work in several top-tier academic publications I co-authored on the topic. I will then present four misconceptions around language-based sandboxing, underlying more than 20 zero-day vulnerabilities I discovered in the past six months in popular projects across JavaScript and Python, revealing fundamental flaws in isolation approaches. We will examine why built-in isolation primitives like Node.js's vm module and Python's Pysandbox fail to provide adequate security, and explore the real-world consequences through case studies involving major platforms. The talk will then shift to practical solutions, covering best practices and emerging isolation features, including the permission model in modern runtimes like Deno. Attendees will gain a deeper understanding of the isolation landscape and leave with actionable guidance on how to safely handle untrusted code execution in their applications. While this talk is not an endorsement for using eval-like features in scripting languages, it is a guide about the things that work in practice and about the ones that fail spectacularly in production.

Everyone expects Identity & Access Management to be a "set it and forget it" problem. But the reality looks quite different: the same challenges keep resurfacing, they are technically demanding, time-consuming, and frequently create friction between teams, ultimately resulting in significant costs. And the rise of AI agents makes it even worse.

Over the years, I explored these recurring issues, which led to a multi part blog series (https://www.innoq.com/en/blog/2025/07/whats-wrong-with-the-current-owasp-microservice-security-cheat-sheet/) published in 2025, initially aimed at updating the OWASP Microservice Security Cheat Sheet. My goal was to show how well known IAM building blocks can be combined into pragmatic, coherent, and operationally realistic solutions. That work eventually grew beyond the original scope and is becoming multiple new OWASP Cheat Sheets plus an entirely new architectural-level cheat sheet format.

In this talk I'll share the essence of the patterns and the strategies I identified and documented, show how to avoid the usual traps, and how to reduce IAM complexity in distributed systems to create the space to focus on what we're actually building - the product.