Skip to content

Product

What Audixa checks, and where each check runs

Code projects are analysed in Audixa Cloud. Servers, their websites and WordPress are analysed on the server itself by audixa-agent. Both end in the same list of findings.

Code projects

What we check in a repository

Connect a GitHub, GitLab or Bitbucket repository, or upload a ZIP. The scan runs in a throwaway container with networking switched off. Your code is never executed and never kept.
  • Secrets in code and configuration

    API keys, private keys, access tokens and database credentials committed to the repository. Matched by pattern and entropy, then redacted before anything is stored.

    Audixa Cloud · secrets rules

  • Vulnerable dependencies

    The exact package versions from your lockfiles, checked against published advisories. Nothing is installed and no build runs.

    Audixa Cloud · OSV advisory data

  • Static rules for access control and unsafe flows

    Command injection, dynamic evaluation, authorization checked only in the frontend (IDOR/BOLA), webhooks without signature checks and payment amounts the client can tamper with.

    Audixa Cloud · Audixa rule packs

  • Live domain configuration

    TLS, security headers, cookies, CORS and redirects, read from the domain itself — only after you have proved you control it, and with no exploitation attempted.

    Audixa Cloud · verified domains only

Servers and WordPress

What audixa-agent checks on a server

Install audixa-agent on a Linux server, or add the Audixa extension to Plesk or the plugin to cPanel/WHM. The agent finds the websites and WordPress installations on the server and analyses them where they run.
  • Inventory of the server

    The websites on the server, their document roots and TLS, and every WordPress installation with its core version, plugins and themes. Discovered by the agent, not typed in by hand.

    audixa-agent · light job

  • WordPress audit

    Components with known vulnerabilities, core files that do not match the official checksums, debug mode left on, the file editor enabled, PHP allowed in uploads, XML-RPC and user enumeration exposed.

    audixa-agent · standard job

  • Server audit

    SSH root login and password authentication, an inactive host firewall, pending security updates, an end-of-life operating system, risky PHP settings, directory listing, legacy TLS and exposed backups.

    audixa-agent · standard job

  • Malware scans

    A scan of recently changed files, or a full scan of a site, against known malicious patterns. A full scan is a heavy job: it runs only when the server is healthy.

    audixa-agent · light or heavy job

  • Quarantine and restore, when you confirm

    A suspicious file can be moved to quarantine and put back later. Both are requested by you, ask for confirmation, and are checked against the file's hash before they count as done.

    audixa-agent · change to the server

Read the scheduling rules in full

What you get back

Four things, for every analysis

  1. A finding you can act on

    Plain-language summary, impact, the evidence it came from, the steps to fix it, 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 the last analysis

    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 analysis

    Which checks ran, which were skipped, and why — an unverified domain, a language we have no rule pack for, a job that needs a newer agent. A clean result is only meaningful next to its scope.

What a finding looks like

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.

What is true today

What Audixa does now, and what it does not do yet

Nothing in the “Not active yet” column is sold in any plan. When something moves from one column to the other, this page changes.

Available today

  • Repository and ZIP scans in Audixa Cloud
  • Live checks on a domain you have verified
  • Server and WordPress audits through audixa-agent
  • Malware scans of a site, with quarantine and restore you confirm
  • Plesk extension and cPanel/WHM plugin
  • AI explanations and suggested fixes, opened as a pull request only when you ask

Not active yet

  • Real-time malware monitoring and file-integrity watching
  • Automatic responses to an attack
  • Enforcing WAF rules on the web server
  • Safe plugin and core updates through a staging copy

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 we were able to examine. It is useful for spotting a direction of travel between analyses.

It is not a measurement of how secure your application is, and it is not comparable to anybody else's score. Every score links to 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 or your server

Connect a repository or a server, run one analysis, and read the findings. If there is nothing to fix, you will see which checks said so.

Create your accountCompare the plans

No automatic changes to your code or your servers.