Skip to content
Audixa
Audixa

Product

A security review of the application you actually shipped

Audixa reads your repository and, once you have proved you control it, the configuration your domain serves. It reports what it found, what it is based on, and what it did not evaluate.

The checks

Eight categories

We use established tools where good ones exist and write our own rules where they do not. Everything is normalised into one finding format, so results from four different engines read the same way.

  • Secrets

    API keys, access tokens, private keys, hard-coded credentials and environment files that ended up committed. Matched by pattern and by entropy, then verified against the surrounding code so a test fixture is not reported as a live key.

    gitleaks + our own rules

  • Dependencies

    Your lockfile becomes an inventory of exact versions, which is checked against published advisories. Nothing is installed, resolved or executed to produce it — which also means a private registry does not have to let us in.

    OSV advisory data

  • Dangerous code patterns

    Dynamic evaluation of strings, shell commands assembled from request data, unsafe deserialisation, predictable randomness used for tokens or identifiers, secrets written to logs, and file handling that trusts a user-supplied path.

    Opengrep + first-party rule packs

  • Authentication

    Routes that reach data without an authentication check, sessions that never expire, tokens signed with a weak or absent secret, and login flows that reveal whether an address is registered.

  • Authorization

    The category that produces the most damaging findings: permission checks that exist only in the frontend, role checks applied on some routes and not others, and record lookups by client-supplied id with no ownership condition.

  • APIs and data exposure

    Debug and introspection endpoints left enabled, routes intended to be internal that are reachable from the internet, and responses that serialise a whole database row when the page needs three fields of it.

  • Deployment configuration

    Checked against the live domain, once you have verified it: certificate and protocol basics, security headers, cookie attributes, CORS rules, redirect behaviour, and version information disclosed in responses.

  • Payments

    When a payment provider is detected: a secret key used where a publishable one belongs, webhook handlers that skip signature verification, amounts or plan state taken from the browser, and entitlements granted without a server-side check.

What you get back

Four things, for every scan

  1. A finding you can act on

    Plain-language summary, business impact, the evidence it came from, the remediation steps, and the technical detail underneath for whoever wants it.

  2. Severity and confidence, separately

    How much it matters and how sure we are are two different questions. A high-severity finding we are not certain about says so, instead of being quietly downgraded or quietly promoted.

  3. A comparison with your last scan

    New, still present, resolved, or back again. A single point-in-time result cannot tell you whether your fix worked; two can.

  4. The coverage of the scan

    Which checks ran, which were skipped, and why — an unverified domain, a language we have no rule pack for, a repository too large to read in full. A clean result is only meaningful next to its scope.

An example

What a finding page contains

The order is fixed: what could happen, then the evidence, then the fix, then the vocabulary. It is the order somebody needs the information in, which is not the order a scanner produces it in.
CriticalConfidence: likelyAccess control

A signed-in user could read another customer’s order by changing an id in the address bar

This endpoint looks up an order by the id in the URL and returns it without checking who is asking. Anyone with an account can put somebody else’s order id in and read the name, address and items on it. Order ids are sequential, so they do not have to guess.

// app/api/orders/[id]/route.ts export async function GET(request, { params }) {  const order = await db.order.findUnique({    where: { id: params.id },  });   return Response.json(order);}

Three lines either side of the match, with anything that looks like a secret removed before it is stored.

How to fix it

  1. Work out who is making the request on the server, from the session — not from anything in the URL or the request body.
  2. Add the owner to the query itself, so the database returns nothing when the order belongs to someone else.
  3. Answer “not found” rather than “not allowed”, so the response does not confirm that the order exists.
  4. Re-scan to confirm the finding is gone rather than assuming it is.
Technical detail

Broken object-level authorization, commonly written IDOR or BOLA. The handler performs a primary-key lookup with a client-supplied identifier and no ownership predicate, so authorization is missing rather than incorrect.

Rule authz/idor-route-param, matched on a route handler that reaches a data-access call with a path parameter and no tenant or owner constraint on the query.

Boundaries

What this product does not do

Worth reading before you sign up rather than after. If one of these is the thing you needed, we would rather you found out now.
  • A clean scan means the checks we ran found nothing — not that your application is secure. We tell you which checks ran and which did not.
  • We do not attempt to exploit anything. No brute forcing, no port scanning, no destructive payloads.
  • We do not review business logic that only a human who knows your product could evaluate.
  • We are not a compliance certification. We do not issue ISO, SOC 2 or PCI attestations, and a scan is not an audit.
  • Automated analysis finds patterns. It misses things, and it sometimes flags something that turns out to be fine — which is why every finding carries a confidence level and its evidence.

A score is a summary, not a measurement

The number on your dashboard is a deduction from the findings we have, weighted by severity and confidence, and capped by how much of your project we were able to examine. It is useful for spotting a direction of travel between scans.

It is not a measurement of how secure your application is, and it is not comparable to anybody else’s score. Every score in the product links to an explanation of exactly how it was calculated and what it left out, and launch readiness never reads as 'safe' — the best it says is that no blocking findings were detected.

Run it against your project and see

One project and one scan a month are free. You see how many findings there are and how severe they are; titles and evidence unlock on a paid plan.

Analyze my projectSee what the paid plans add

Start free. No automatic changes to your code.