Rethinking the Interception Proxy: Why Crusader is Betting on Local-First SQLite

For years, interception proxies have largely followed the same formula. Capture traffic, display requests, allow replay and modification, and store everything inside an internal project format. It is a workflow that has served penetration testers and bug hunters well, but it also creates an unexpected limitation: the data you generate during an assessment often becomes surprisingly difficult to use outside the proxy itself.

Need to correlate thousands of requests with an external script? Build a custom reporting pipeline? Feed historical traffic into an AI agent? Most existing tools require exporting data, writing extensions, or reverse engineering proprietary storage formats before you can even begin.

Crusader takes a different approach.

Currently in public alpha, Crusader is a local-first interception proxy built around a simple architectural principle: your captured traffic should remain your data. Rather than hiding requests inside a proprietary project format, Crusader stores everything in a standard SQLite database that becomes the single source of truth for the entire application.

That design decision affects nearly every part of the product.

Instead of each subsystem maintaining its own isolated state, the desktop interface, command-line tooling, plugin host, and integrated Model Context Protocol (MCP) server all communicate with the same SQLite database. There is no synchronization layer between multiple storage engines and no import/export process just to make captured traffic available elsewhere. Every component is simply another client interacting with the same data.

On paper this sounds straightforward. In practice, it requires careful engineering to avoid contention while maintaining responsiveness.

Crusader relies on SQLite's Write-Ahead Logging (WAL) mode to enable concurrent reads and writes. While the proxy is actively capturing traffic, plugins can analyze requests, command-line tools can perform bulk processing, and the user interface remains responsive because readers are not blocking writers. SQLite has matured into an exceptionally capable embedded database, and for a local-first desktop application it offers reliability without introducing the complexity of running a separate database server.

The second advantage comes from SQLite's JSON capabilities.

Modern APIs are overwhelmingly JSON-driven, yet many proxy tools still treat request and response bodies as opaque text blobs. By leveraging SQLite's JSON functions, Crusader makes structured traffic directly queryable. Instead of exporting history into Python just to filter nested objects, users can execute expressive SQL queries against live interception data.

Need every request that returned HTTP 403 where a nested field contains a particular tenant ID? Looking for all GraphQL operations containing a specific mutation? Searching for responses that expose a certain JWT claim? These become database queries instead of custom parsing scripts.

The benefit is not simply convenience. It fundamentally changes what captured traffic can become.

Because the underlying storage is an open database rather than a proprietary format, researchers can build workflows around familiar tooling. Python, Go, Rust, PowerShell, shell scripts, data visualization platforms, and countless other tools already understand SQLite. There is no vendor-specific SDK required to access your own assessment history.

This architecture also aligns naturally with the growing role of AI-assisted security research.

Crusader exposes its live database through an integrated MCP server, allowing compatible AI agents to inspect captured traffic while an assessment is in progress. Instead of working from static exports or manually curated context, an agent can query live requests, examine responses, identify patterns, and generate follow-up analysis based on the current interception history.

That does not replace human expertise, but it removes much of the friction involved in giving AI systems meaningful context. As security workflows increasingly combine human judgment with automation, keeping proxy data in an open, queryable format becomes a practical advantage rather than simply an architectural preference.

Beyond the storage layer, Crusader is being developed with modern web applications in mind. Native HTTP/2 and WebSocket support, mobile application interception, and identity-aware replay workflows are intended to reduce the amount of manual work required during contemporary assessments instead of treating newer protocols as afterthoughts.

Perhaps the most interesting aspect of Crusader is not any individual feature, but the philosophy behind it. Instead of assuming the interception proxy should be the center of your workflow, it treats the proxy as one participant in a broader ecosystem of scripts, automation, AI tooling, and custom analysis pipelines.

Your interception history is no longer trapped inside the application that captured it. It becomes a local, searchable, scriptable dataset that belongs to you.

For an industry increasingly driven by automation and rapid experimentation, that may prove to be a more significant shift than any new button or feature added to the interface.

One capability that genuinely stood out during testing had nothing to do with databases or protocol support. Crusader's plugin system is built around JavaScript, and the difference in developer experience is immediately obvious. As an experiment, I asked ChatGPT to write a simple plugin, copied the generated JavaScript into Crusader Proxy (https://crusaderproxy.com), and had it running in under a minute without making a single modification. It worked exactly as expected. That is a significant departure from the traditional extension ecosystem many security professionals have grown accustomed to. Writing Burp extensions often means dealing with Java or Kotlin, navigating a large API surface, or learning BChecks for narrower use cases. Those technologies are certainly powerful, but they also raise the barrier to creating quick, task-specific tooling. By lowering that barrier, Crusader makes it realistic for researchers to build custom extensions on demand, whether they are solving a one-off problem during an engagement or rapidly prototyping an entirely new workflow. In an era where AI can generate functional code in seconds, having a lightweight JavaScript plugin model feels considerably more aligned with how security professionals actually work today.

For years, the conversation around interception proxies has revolved around feature parity. Does it have this scanner? That repeater? This decoder? Those are easy comparisons because they assume every proxy is solving the same problem. Crusader quietly challenges that assumption. It asks a different question: what if the proxy wasn't the destination at all? What if it was simply the producer of a living security dataset that every script, plugin, AI agent, and analyst could work from simultaneously? If that idea catches on, we may eventually stop judging interception proxies by how many tabs they have and start judging them by how well they integrate into the rest of our workflow. Looking at Crusader's architecture, that future feels less like a marketing vision and more like an inevitable direction for offensive security tooling.