I’m an application security engineer focused on vulnerability research, web security, and building tools to make application security easier. I founded the OWASP Indianapolis Chapter in 2005 and curate appsec.fyi, a collection of application security resources.
I’ve worked at Microsoft, Proofpoint, Salesforce, Teradata, and Anthem, and I’ve spoken at DerbyCon and CircleCityCon on topics like extending Burp Suite and Ruby security.
Recent Posts
AppSec.fyi Hits 2,200+ Resources: What's New
Back in January I wrote about the launch of AppSec.fyi, the curated application security resource library I built and maintain. Three months later, I’ve added enough to warrant an update. What started as a clean list of links organized by vulnerability class has turned into something closer to a full reference platform. By the Numbers The resource count has crossed 2,241 items spread across 24 distinct categories. That’s a significant jump from the handful of core vulnerability classes I launched with. The original categories — XSS, SQLi, SSRF, IDOR, XXE, RCE, CSRF — are still there, but I’ve expanded into areas that reflect where application security is actually headed.
MCP Tool Poisoning: The Attack Surface Nobody's Talking About
I run about a dozen MCP servers in my daily workflow. Playwright for browser automation, Raindrop for bookmarks, Todoist for tasks, a couple of custom ones. Every time I start a Claude Code session, my agent loads all of their tool descriptions into context and uses them to decide what to call. Last month I started thinking about what would happen if one of those tool descriptions was lying to me.
csp-toolkit: Analyzing Content Security Policy Headers at Scale
There’s no Python library for parsing Content Security Policy headers. I checked PyPI, I checked GitHub — nothing. Google has a CSP Evaluator web tool and an npm package, but if you want to analyze CSP programmatically in Python — for recon scripts, bug bounty automation, or CI pipelines — you’re on your own. So I built one. csp-toolkit is a Python library and CLI tool that parses CSP headers, runs 21 weakness checks, finds bypass vectors against a database of 79 known-exploitable domains, scores policies A+ to F, and does a lot more. The current release is v0.6.2 on PyPI (changelog).
Use-After-Free: Understanding a Classic Memory Corruption Bug
Use-after-free (UaF) vulnerabilities are one of the most exploited classes of memory corruption bugs. They’ve been at the heart of browser zero-days, Linux kernel privilege escalations, and countless CVEs. Despite being well understood, they remain stubbornly common — a testament to how easy they are to introduce and how hard they are to catch with conventional testing. What Is a Use-After-Free? A use-after-free occurs when a program: Allocates a chunk of memory on the heap Frees that memory (returning it to the allocator) Continues to use a pointer that still references the now-freed region The memory is no longer “owned” by the program. The allocator is free to give it to something else. When the program reads or writes through the dangling pointer, it’s operating on memory that may now belong to an entirely different object — or may have been zeroed, corrupted, or repurposed by an attacker.
CVE-2026-27696: SSRF in changedetection.io via URL Validation Bypass
A high-severity SSRF vulnerability (CVSS 8.6) was disclosed on February 25, 2026 in changedetection.io, a popular open-source tool for monitoring web page changes. The bug is a textbook example of a failed allowlist/denylist approach to URL validation — and the default unauthenticated configuration makes it exploitable by anyone with network access to the instance. What is changedetection.io? changedetection.io is a self-hosted service that watches URLs for content changes and alerts you when something changes. It’s commonly used by developers, researchers, and sysadmins to monitor pages, APIs, and dashboards. The tool fetches URLs on your behalf — which is exactly the trust relationship SSRF attacks exploit.