Steven Morrison
HomeDev JournalProjects
← Back
Series

Building a Web Security Tool

Part 1: The beginning

The what and why

In this series I will be documenting my journey building a web security tool. Specifically, a tool to aid the security testing of web applications - think Burp Suite or Zed Attack Proxy (ZAP). The main goal is to allow users to intercept, modify, drop and forward HTTP(S) traffic, along with extra features some of which may be inspired by existing tools.

My motivation for doing this is simply, I’m interested in security, I’ve used similar tools before and thought a great project would be to try to build my own! Additionally, it allows me to build a project that is super tailored to my own workflow, one that might not be totally possible with existing solutions.

One important point to make is that this is not a tutorial, its simply a journal of my experience. I may drill into details on the things that I think are important, such as challenges that I faced and how I solved them, which I hope might be interesting and/or beneficial to anyone who happens to read this. Once I have reached my MVP goals, I will make the source code public and link it here.

Tech stack

There’s probably a few different formats that you could choose for the tool such as; a desktop app, web app or maybe even a browser plugin. I think a desktop application gives more control and possibilities for the type of features that I want to build - we aren’t limited to what we can do within a browser, and it makes things more interesting so that’s the format I’d like to target.

When building a desktop application, there are a few different avenues that you can go down. I wanted the application to be cross-platform but I didn’t want to get bogged down with the implementation or OS specifics. So I explored frameworks like Flutter but was looking for something thats less opinionated and more familiar. Specifically I liked the idea of using web technologies to build the UI. In the past I had used Electron (chromium based) but I didn’t really enjoy the experience and the end result felt a bit bloated. For these reasons I leaned towards a native + web view approach which included frameworks like Wails and Tauri. In the end I chose Wails as I have toyed with it previously and I enjoy Go. To speed up UI development I paired Go with Vue.js and TailwindCSS.

The roadmap

I didn’t want to think too far into the future yet, but I did have vague ideas such as exploring local AI models to enable cool features. Those aside, I think the main set of features needed for this tool to be useful (MVP) are:

  • Proxy server used to intercept HTTP(S) traffic
  • Ability to inspect raw request and response payloads (no syntax highlighting or formatting yet)
  • Ability to Intercept and modify traffic (w/ forward only)

I think those form the base which can then be followed up by some additional features:

  • Configuration: proxy port, target scope
  • Preconfigured browser: setup to use proxy with appropriate certs
  • Drop intercepted traffic
  • Filter and search for traffic history
  • Syntax highlighting and formatting for traffic
  • Persistence: save projects w/ scope and config
  • Local AI features: needs exploration

What’s next

In my next posts I aim to talk about setting up the proxy server and will touch on the challenges with HTTPS and TLS.