FiretrailDocs
Open app

Security Audit

Most security problems in a working application are not exotic. They are the same five mistakes, made in ordinary code by people in a hurry: a list query that forgot to filter by the current customer, an admin action the interface hides but the server never checks, a record anyone can fetch by changing the ID in the URL, a key pasted into a config file, a piece of user text rendered as HTML. A Security Audit looks for exactly those five, everywhere in the codebase, and reports only what it could prove.

The result is one page the whole team can read, not a report only a security engineer understands:

  • Fix these first — the critical and high findings, open at the top, each with where it is, why it matters in plain words, and the fix.
  • Findings by severity and by check — how much there is and where it concentrates, at a glance.
  • What is already protected — the things the audit verified are done right, with the file or router as evidence. This is the proof of coverage, and it tells the team where not to spend time.
  • The five checks, one section each. Every section opens with what that failure is, how an attacker uses it and what a safe version looks like, in the same words on every audit — so a finding is never a label you have to look up. Your findings follow, collapsed, each with the snippet, why it is exploitable, the impact, any condition it depends on, and the fix.
  • Recommendations in order — P1 fix now, P2 this sprint, P3 hardening.
  • Ready-to-file GitHub issues — one per actionable finding (related small ones grouped), in Markdown with a copy button: problem, evidence, impact, suggested fix and acceptance criteria.
  • How the audit was run — what was covered, how each check was mapped onto your stack, and the severity scale.

The page prints cleanly to PDF from the browser when someone needs a file.

The five checks

  1. Data fenced per customer. Every list, search, report and export must only return rows that belong to the person asking. The audit first works out how your app does that (row-level security, a tenant middleware, manual scoping) and then looks for where it is missing.
  2. Permissions decided in the browser. The interface hides a control by role, but the server behind it does not check who is calling. The audit crosses every frontend role gate with its endpoint.
  3. Records reachable by changing an ID (IDOR). Routes that load an object by ID without checking it belongs to the caller. The audit walks every route handler, not a sample, and says how many it walked.
  4. Secrets written into the code. Keys, passwords and signing secrets in source, config, Docker, CI, charts, scripts or docs — including defaults that become the real secret when nobody overrides them, secrets still in git history, and keys shipped in the frontend bundle.
  5. User input rendered as HTML (XSS). innerHTML and its equivalents, unsanitized markdown, user-controlled links, eval — and the same failure in server-side emails and templates.

When a check does not apply to your stack (no frontend, no database), the audit says so instead of forcing findings.

How it's built

Your own coding agent (Claude Code, Cursor, Codex, VS Code or any MCP client) does the reading, in your checkout, on your own account. It detects the stack, runs the five checks against the real code and reports only what it verified — file, line, the snippet, why it is exploitable, and a fix. Firetrail contributes what it already knows about the repository as leads: the review team's findings in the security and privacy lanes on recent pull requests, and the files with a history of causing bugfixes. Then Firetrail renders the page itself and hosts it at its own link, adding the ranking, the charts, the explanation of each check and the issues. Firetrail never reads your working tree and runs no AI of its own for an audit.

Running one

Connecting your agent to Firetrail takes two steps, once per person (see Firetrail MCP, or the Firetrail MCP page in your account menu): create a personal token, then add the Firetrail server to your agent with the snippet the page shows for it.

Then, in a checkout of the repository, ask the agent:

Security audit this repository with Firetrail

To focus on one pull request instead — the files it touches and the code paths they reach — name it:

Security audit PR 123 with Firetrail

(In Claude Code the slash command /mcp__firetrail__security_audit is the exact equivalent — that is Claude Code's naming for anything an MCP server provides; both do the same thing.)

A whole-application audit takes the agent a while: it reads every route handler and every deploy file. The agent hands the results to Firetrail, which renders and hosts the page and returns the link. Republishing an audit later keeps the same link, so the page a team bookmarked stays current.

Availability

Security Audit is on every plan. The reading and the verifying run in each developer's own coding agent, on their own account, so Firetrail doesn't meter that part; the page is rendered from what the agent reports and from analysis Firetrail already ran, at no extra cost. Like every Firetrail artifact, the page is private to your organization by default and can be flipped to a public link when you want to share it beyond your team.