Let’s be honest: API documentation is usually a mess, and security is often an afterthought handled by a separate team weeks after the code is written.
I’ve been working on a logic-heavy approach to fix this. Instead of just scanning for open ports or missing headers, I wanted to build something that actually understands the intent of the endpoint.
The goal? To bridge the gap between a raw OpenAPI spec and a production-hardened API without the manual back-and-forth.
What it does (The "Meat")
I’ve put together a short video walkthrough (link below) showing the core engine. Here’s the breakdown of what’s happening under the hood:
Logic Mapping: It distinguishes between public health checks and sensitive data clusters automatically.
Risk Scoring: It’s not just "High/Low." It uses a scoring matrix (Data Risk x Linkability) to quantify exposure.
The "Simulation" Layer: This is my favorite part—you can preview how applying a fix (like BearerAuth enforcement) changes your compliance posture before you touch a single line of code.
A quick look at the "Enforcement" flow:
In the video, you’ll see the engine analyzing a /products endpoint. It detects it’s public-facing but lacks hygiene, then suggests a specific security injection.
Note: This isn't a finished product yet. It's a technical demo of the "Intent-Aware" logic I'm developing.
I need your "Dev" feedback
Since this is still in the early stages, I’m curious about a few things:
Does the "Risk Scoring" approach make sense to you as an architect?
Would you find a "Simulation Mode" useful in your CI/CD pipeline, or is it too much noise?
Check out the demo here: [https://youtu.be/64tosPvVwvE?si=tpFTIBUdjh32QwhC]
Looking forward to some brutal honesty in the comments. 🛠️
Top comments (0)