Eliminating entire classes of vulnerabilities, at the scale of billions of users.

// 01 · work @ googlesecure by design, not by chance

script-src 'sha256-O/U1gaHM7ZtQSgoX3D5yIq49fahCU+BPCnS/0K+EiX4=';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
trusted-types 'none';

// 02 · selected worksix things worth your time

• 01CSP Is Dead, Long Live CSP!

  The internet-scale study that showed 99% of CSP deployments protected nothing against XSS. It introduced strict-dynamic (ACM CCS 2016).

  paper · doi
• 02Strict CSP

  From a research paper to 30%+ of global page loads.

  chrome data · web.dev guide
• 03Secure by Design

  Google's blueprint for high-assurance web frameworks. The result: "less than one XSS report per year" across the hundreds of complex apps built on them.

  blueprint · overview paper
• 04Securing AI Agents

  I started Google's AI Agent Security team in 2023. Prompt injection has no clean fix, so we contain it: the defense-in-depth behind Google's public SAIF.

  talk · saif.google
• 05Google I/O '19

  The browser defenses we helped build (CSP, Trusted Types, COOP, Fetch Metadata) that move security off developers and into the platform.

  deck
• 06LocoMocoSec keynote

  How we rolled out security across 1,000+ web apps, where a single outage would cost millions.

  deck

// 03 · ~/aboutone problem, several directions

// 04 · ~/workby theme, not by org chart

web platform security

The thesis: XSS and other common web vulnerabilities survive because we ask every developer to be perfect. Strict CSP, Trusted Types, Fetch Metadata, and COOP move the burden into the platform. My team and I rolled these out across Google's most sensitive surfaces — Gmail, Search, YouTube, Drive, Docs, Cloud Console, Accounts — over years, because an outage there is measured in millions. Today these protections cover the majority of Google's sensitive Front End traffic.

Where it compounds: high-assurance frameworks. Across the hundreds of complex web applications built on Google's hardened, secure-by-design frameworks, we've "averaged less than one XSS report per year in total." XSS in core Google products is down 90% over the past decade (An Overview of Google's Commitment to Secure by Design, Google, 2024, p. 7). How we achieved this is public: Secure by Design (talk).

agentic web security

Not securing agents — using agents to transform how classical web security gets done. I set up Google's three-part strategy: find agents that discover vulnerabilities autonomously; patching agents that generate and ship fixes automatically, work that contributed to Google DeepMind's CodeMender; and teaching the underlying models safe coding, so AI-written code uses safe APIs by default. The same tools are changing how we clear hardening backlogs and run the VRP.

ai agent security

The other team I lead, started in 2023, focused on securing AI agents themselves. Agents are non-deterministic and take in untrusted input; they can be manipulated into rogue actions or sensitive-data exfiltration, and there is no known way to prevent prompt injection outright. So we contain it: a hybrid defense-in-depth that pairs deterministic policy enforcement with model-based defenses, limits an agent's powers, and keeps its actions observable. Our approach is a core part of Google's public Secure AI Framework, and the team's paper — Google's Approach for Secure AI Agents — became one of the most-cited papers in the field, on Google Research's popularity charts second only to "Attention Is All You Need". In practice, the same team helps secure Gemini and Search's AI features.

The two areas are distinct, but they compound: we can only secure agents well because we build with them every day, and the agent security we build is what lets us ship powerful, safe agents for web security.

measurability

You can't secure what you can't measure. I bootstrapped Google's Product Security Measurability programme and co-authored Security Signals (NDSS MADWeb 2025): security posture extracted from production HTTP traffic at the reverse proxy, across 8,000+ services and ~1,000 domains, trillions of requests, used by 60+ teams. The synthetic-signals approach behind it is patent-pending. On top of it: Long-Lived Stable Metrics for Web Security, Memory Safety and Crypto Hygiene, measuring how much of the ecosystem is secure by architecture, not how many bugs are open. It's how we track adoption of the hardened frameworks, and increasingly of our AI agents, turning "are we secure by design?" into a number leadership can act on.

tools

• CSP Evaluator

  Checks whether a Content Security Policy actually mitigates XSS — and flags the subtle bypasses that make most policies useless.

  XSS mitigationstrict CSP
  tool · source
• strict-csp

  Webpack plugin: hash-based strict CSP for single-page apps — no refactoring required.

  webpackhash-based CSP
  source
• VSAQ

  Vendor Security Assessment Questionnaire — open-sourced in 2016.

  vendor security
  source · demo · blog

// 05 · ~/specsW3C WebAppSec WG · member since 2019

• 01 CSP Level 3 Significant contributor. Introduced strict-dynamic and other CSP3 features, moving CSP from fragile host allowlists to deployable nonces and hashes. strict CSP
  tl;dr

  Allowlists don't work. Nonces and hashes do.

  In our internet-scale study (~100B pages), 94.68% of policies that tried to restrict script execution were bypassable: a single JSONP endpoint or open redirect inside an allowlisted domain voids the whole policy. strict-dynamic roots trust in a cryptographic nonce or script hash instead, and lets trusted scripts propagate that trust to whatever they load. The allowlist, and its bypasses, stop mattering.

  Content-Security-Policy:
    script-src 'nonce-sd0f98a7' 'strict-dynamic';
    object-src 'none'; base-uri 'none';
  # scripts need the nonce/hash; what they load is trusted transitively

  This pattern now runs on 30%+ of global page loads.

• 02 Trusted Types Significant contributor. DOM sinks only accept typed, validated values; DOM XSS becomes a type error, not a runtime surprise. DOM XSS
  tl;dr

  DOM XSS becomes a type error.

  The DOM has dozens of injection sinks (innerHTML, document.write, eval), and any string that reaches one is a potential XSS. With Trusted Types enforced, sinks refuse plain strings and accept only typed values. Two ways to satisfy that, from pragmatic to absolute:

  1 · validate at the one chokepoint

  When a value is supposed to be simple, a policy that allowlists its shape beats any sanitizer. The whole security review is one regex:

  Content-Security-Policy: require-trusted-types-for 'script'
  
  // the classic that survives code review — attacker controls ?id=
  badge.innerHTML = new URLSearchParams(location.search).get('id');
  // ✗ TypeError: innerHTML requires TrustedHTML, got string
  
  const policy = trustedTypes.createPolicy('id', {
    createHTML: (s) => {
      if (!/^[a-z0-9]+$/i.test(s)) throw new TypeError('unsafe: ' + s);
      return s;   // alphanumeric → no < > & " ' to abuse
    }
  });
  badge.innerHTML = policy.createHTML(id); // ✓ or throws

  2 · or go policy-free: "perfect types"

  Add trusted-types 'none' and no policy can be created at all. There's no way to mint a typed value, so string sinks become permanently unreachable. The code has to use safe, structured DOM APIs:

  Content-Security-Policy: require-trusted-types-for 'script'; trusted-types 'none'
  
  el.innerHTML = anything;              // ✗ always throws — no escape hatch
  trustedTypes.createPolicy('x', …);   // ✗ blocked by 'none'
  
  el.textContent = userText;            // ✓ text, never parsed as HTML
  const a = el.appendChild(document.createElement('a'));
  a.textContent = label;                // ✓ structured, not string-built

  This site is built the second way: its one script only ever sets textContent: no policy, no sinks, nothing to review.

• 03 Fetch Metadata Significant contributor. Sec-Fetch-* headers let servers reject cross-site attacks before they hit application logic. CSRF · XSSI
  tl;dr

  Reject cross-site attacks before your code runs.

  The browser annotates every request with its provenance: who initiated it (Sec-Fetch-Site), how (Sec-Fetch-Mode) and as what (Sec-Fetch-Dest). A resource isolation policy, a few lines at the front door, rejects the cross-site requests your app never meant to serve. It kills CSRF, XSSI and cross-site leaks on the server, before any application logic runs.

  # attacker-initiated fetch arrives as:
  Sec-Fetch-Site: cross-site   Sec-Fetch-Dest: image
  
  # resource isolation policy — first thing on every request:
  allow same-origin | same-site | none; allow top-level navigations;
  everything else → 403

• 04 Cross-Origin Opener Policy Contributor. Process isolation against XS-Leaks and transient-execution attacks. XS-Leaks
  tl;dr

  Your tab, your process.

  window.opener hands a cross-origin page a live handle to your window: enough for XS-Leaks like frame counting, and since Spectre, enough to matter at the process level. COOP: same-origin severs that handle and lets the browser give the page its own process. One header, one class of side channels gone.

  Cross-Origin-Opener-Policy: same-origin
  
  window.opener === null  // from any cross-origin opener

Beyond the specs: led several multi-year collaborations with Mozilla, Apple and Igalia to bring Trusted Types, Fetch Metadata, and CSP3 to Firefox and Safari. A spec only counts once every browser engine implements it.

// 06 · ~/talks31 talks · 6 guest lectures · since 2009

• 2026OWASP AppSec Days Portugal, PortokeynotefeaturedIt's Never Been Easier to Write (In)Secure Software: Turning AI, the Fastest Coder, into the Safestsession
• 2026SIGS — Security Interest Group Switzerland, ZürichfeaturedFrom Prompt Injections to Rogue Actions: Securing AI Agents in Practiceslides
• 2025Google init.g, Mexico CityWeb security introduction for studentsrecap
• 2024LocoMocoSec, Kaua'ikeynotefeaturedGoogle's Recipe for Scaling (Web) Securitydeck
• 2024W3C TPAC, Los Angeles
• 2024P19 Payment Festival, Viennapanel
• 2023SecAppDev, LeuvenModern security features for web appssession · slides
• 2023Belgium Cyber Security Coalition, Leuven
• 2022sec4dev, ViennaSecuring Web Applications with Modern Web Platform Security Featuressession · slides
• 2019Google I/O, Mountain ViewfeaturedSecuring Web Apps with Modern Platform Featuresrecording · deck
• 2019LocoMocoSec, KauaiCSP: A successful mess between hardening and mitigationdeck
• 2019PyConWeb, MunichkeynotefeaturedSecurity for modern web apps
• 2019OWASP AppSec, Tel Aviv
• 2019W3C TPAC, Fukuokaminutes
• 2019IT-SECX, St. PöltenSecuring web apps with modern platform featuresprogramme
• 2018Hack In The Box, AmsterdamDefense-in-depth techniques for modern web applicationsprofile · slides
• 2018Area41, Zürich
• 2018ScaleUp Porto Masterclass, Porto
• 2018Confidence, Kraków
• 2017OWASP New Zealand, Auckland
• 2017Hack In The Box, Amsterdam
• 2017OWASP AppSec, BelfastSo we broke all CSPs… You won't guess what happened next!
• 2016ACM CCS, ViennafeaturedCSP Is Dead, Long Live CSP!paper · doi
• 2016IEEE SecDev, BostonAdopting Strict CSP for XSS Protectionieee
• 2016OWASP AppSec Europe, RomeMaking CSP Great Againsession · deck
• 2016DeepSec, ViennaCSP Is Dead, Long Live Strict CSP!deck · abstract
• 2016Area41, ZürichBreaking Bad CSPdeck
• 2016Hack In The Box, AmsterdamCSP Odditiessession
• 2011ADV Tagung, Vienna
• 2010L.S.Z. Security Kongress, Waidhofen/Ybbs
• 200916. Symposium SICHERHEIT, Vienna

university guest lectures

• 2023KTH Royal Institute of Technology, Stockholmguest lecture — web security
• 2023Technical University of ViennaSystems & Application Security
• 2021KTH Royal Institute of Technology, Stockholmguest lecture — web security
• 2019Technical University of ViennaAdvanced Internet Security
• 2016Chalmers University of Technology, Göteborglecture + PhD workshop
• 2016ETH ZürichNetwork Security

programme committees & peer review

NDSS MADWeb (2021) · USENIX WOOT (2020, 2019)

// 07 · ~/pubsresearch.google · scholar · dblp

• 2025Security Signals: Making Web Security Posture Measurable at ScaleSpagnuolo, Dworken, Janc, Díaz, Weichselbaum · NDSS MADWeb
  abstract

  The area of security measurability is gaining increased attention, with a wide range of organizations calling for the development of scalable approaches for assessing the security of software systems and infrastructure. In this paper, we present our experience developing Security Signals, a comprehensive system providing security measurability for web services, deployed in a complex application ecosystem of thousands of web services handling traffic from billions of users. The system collects security-relevant information from production HTTP traffic at the reverse proxy layer, utilizing novel concepts such as synthetic signals augmented with additional risk information to provide a holistic view of the security posture of individual services and the broader application ecosystem. This approach to measurability has enabled large-scale security improvements to our services, including allowing prioritized rollouts of security enhancements and the implementation of automated regression monitoring; it has proven valuable for security research and prioritization of defensive work.

  pdf · patent
• 2020Information Leaks via Safari's Intelligent Tracking PreventionJanc, Kotowicz, Weichselbaum, Clapis · arXiv:2001.07421
  abstract

  Intelligent Tracking Prevention (ITP) is a privacy mechanism implemented by Apple's Safari browser, released in October 2017. ITP aims to reduce the cross-site tracking of web users by limiting the capabilities of cookies and other website data. As part of a routine security review, the Information Security Engineering team at Google has identified multiple security and privacy issues in Safari's ITP design. These issues have a number of unexpected consequences, including the disclosure of the user's web browsing habits, allowing persistent cross-site tracking, and enabling cross-site information leaks (including cross-site search).

  pdf · bib · arXiv
• 2016Adopting Strict Content Security Policy for XSS ProtectionWeichselbaum, Spagnuolo, Janc · IEEE SecDev
  abstract

  Content Security Policy is a mechanism designed to prevent the exploitation of XSS — the most common high-risk web application flaw. CSP restricts which scripts can be executed by allowing developers to define valid script sources; an attacker with a content-injection flaw should not be able to force the browser to execute arbitrary malicious scripts. Currently, CSP is commonly used in conjunction with domain-based script whitelists, where the existence of a single unsafe endpoint in the script whitelist effectively removes the value of the policy as a protection against XSS.

  ieee
• 2016CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security PolicyWeichselbaum, Spagnuolo, Lekies, Janc · 23rd ACM CCS
  abstract

  Content Security Policy is a web platform mechanism designed to mitigate cross-site scripting (XSS), the top security vulnerability in modern web applications. In this paper, we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies. We base our Internet-wide analysis on a search engine corpus of approximately 100 billion pages from over 1 billion hostnames; the result covers CSP deployments on 1,680,867 hosts with 26,011 unique CSP policies — the most comprehensive study to date. We identify three common classes of CSP bypasses and explain how they subvert the security of a policy. In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS. Finally, we propose the 'strict-dynamic' keyword, an addition to the specification that facilitates the creation of policies based on cryptographic nonces, without relying on domain whitelists.

  pdf · bib · doi
• 2014Andrubis — 1,000,000 Apps LaterLindorfer, Neugschwandtner, Weichselbaum, Fratantonio, van der Veen, Platzer · BADGERS @ ESORICSpdf · bib
• 2014Andrubis: Android Malware Under the Magnifying GlassTR-ISECLAB-0414-001 · Technical University of Vienna
  abstract

  To deal with the increasing numbers of malicious Android apps in the wild, malware analysts typically rely on analysis tools to extract characteristic information about an app in an automated fashion. In this paper we present ANDRUBIS, a completely automated, publicly available and comprehensive analysis system for Android applications. ANDRUBIS combines static analysis techniques with dynamic analysis on both Dalvik VM and system level, as well as several stimulation techniques to increase code coverage.

  pdf · bib

articles & write-ups

• 2024Secure by Design: Google's Blueprint for a High-Assurance Web FrameworkGoogle Bug Hunters Blog
• 2024An Overview of Google's Commitment to Secure by Designcontributor — wrote the web security section
• 2021Mitigate XSS with a strict Content Security Policyweb.dev
• 2020Protect your resources from web attacks with Fetch Metadataweb.dev
• 2020Towards native security defenses for the web ecosystemGoogle Security Blog
• 2016Reshaping web defenses with strict Content Security PolicyGoogle Security Blog
• 2016Scalable vendor security reviewsGoogle Security Blog

// 08 · ~/contact