Skip to content

Audixa Security Engine · Live v2.4

Check if your app is ready for production.

Find security risks, unsafe configuration, payment issues and access-control problems before your users do.

Start free. No automatic changes to your code.

  • Secrets EngineLive
  • Static Code AnalysisAST & Rules
  • Dependencies SBOMLockfile SBOM
  • Attack Surface & Web ConfigSurface Check
Repository

GitHub, GitLab, Bitbucket, or a ZIP. Read-only.

Live site

A verified domain. TLS, headers, and cookies.

checkout-appmain
Demo project
  1. Cloning repository— done
  2. Scanning for secrets— done
  3. Reading the lockfile— done
  4. Static analysis— done
  5. Checking live configuration— done
Security score68
Review recommended
1Critical
1High
1Medium
0Low
0Info
  • A live Stripe secret key is committed to the repository

    Critical.env.local, added 14 commits ago

  • A dependency has a published advisory

    Highimage-pipeline 2.4.1 → 2.4.6

  • The session cookie is served without the Secure flag

    Mediumcheckout-app.example response headers

A scan of a project we built to be insecure on purpose. Not a customer, and not an average.

A fix you approve

The evidence, the steps, and — on plans that include it — a pull request. It is never merged for you.

Compatible with

  • GitHub
  • GitLab
  • Bitbucket
  • WordPress
  • WooCommerce
  • Shopify

What we can show you

No logos, no customer counts, no case studies

Audixa is new. We do not have those things yet, and we are not going to invent them — the rule that stops us telling you your application is secure also stops us inventing a testimonial. What we can show you is how the product is built and what it refuses to do.
  • Read-only repository access

    GitHub permissions ask for contents and metadata only. Audixa cannot push commits, create branches, or touch your repository settings.

  • Isolated container execution

    Code is analysed inside a throwaway container with networking switched off. Your application is never executed or built.

  • Ephemeral workspaces

    The repository clone is deleted the moment the scan finishes, whether it succeeded or failed. We retain findings, not your source code.

  • Deterministic evidence

    Every finding points to specific code or live network responses. We do not generate speculative risks or unverifiable claims.

Read how we protect your data, and what we have not built yet

How it works

Three steps, and none of them involve us running your code

See what happens during a scan, stage by stage
  1. Tell us where your code is

    GitHub, GitLab or Bitbucket with read-only access; a ZIP if the code is not on a host yet; or a verified domain only for live checks. We never run your application.

    GitLab and Bitbucket appear when they are configured on this deployment. A ZIP is deleted when the scan ends.

  2. We run the checks

    Secrets, dependencies, dangerous code patterns, authentication and authorization, exposed endpoints, and the configuration your site actually serves. Your repository is analysed in a throwaway container with networking switched off, and never executed.

    The workspace is destroyed when the scan ends, whether it succeeded or failed.

  3. You act on what matters

    Findings arrive ordered by how much they matter, each with the code it matched, an explanation of what could happen, and the steps to fix it. Fix, re-scan, and see whether it held.

    If you would rather we did the fixing, remediation is one of the services we offer.

Origin

Where is your code?

A scan needs a target. Pick the one you already have. Choosing a ZIP or web-only is not a paid add-on — the plan decides how many projects and scans you have, not where the tree comes from.
  1. GitHub

    Install the GitHub App, pick the repository and branch. Scans clone with a short-lived read token. A write token is minted only when you ask us to open a pull request, and we never merge it.

  2. GitLab

    The same model — read for scans, write only when you ask for a pull request — when the integration is configured on this deployment.

  3. Bitbucket

    Also per repository, when it is switched on. Until then the screen says so plainly. Scans stay read-only; a pull request is opened only if you ask.

  4. A ZIP

    For code that is not on a git host yet. It uses the same scan pipeline and is deleted when the job ends, or when it expires.

  5. The live site only

    TLS, headers and cookies against a domain you have verified. It does not read the repository.

What we analyse

Eight categories, chosen because they are where real incidents start

Established tools where good ones exist, our own rules where they do not. Every result is normalised into the same finding format, so a leaked key and a missing permission check read the same way.
  • Secrets in your code

    API keys, access tokens, private keys and passwords committed to the repository — including the .env file somebody added before .gitignore caught up, and the one deleted in a later commit but still in the history.

    gitleaks + our own rules

  • Vulnerable dependencies

    Your lockfile is read, turned into an inventory and checked against published advisories. We never install a package or run a build to do it.

    OSV advisory data

  • Dangerous code patterns

    Dynamic evaluation, shell commands built from user input, unsafe deserialisation, weak randomness where it needs to be strong, and secrets written to logs.

    Opengrep + our own rule packs

  • Authentication and access control

    Routes with no authentication, permission checks that only exist in the frontend, role checks applied inconsistently, and the object-lookup patterns that let one customer read another's data.

  • Exposed endpoints and data

    Debug routes left enabled, endpoints that were meant to be internal, and responses that return far more of a record than the page they feed actually needs.

  • Deployment configuration

    HTTPS and certificate basics, security headers, cookie flags, CORS rules and redirect behaviour, checked against the domain you have verified.

  • Payments

    Where we detect Stripe or a similar provider: a secret key used where a publishable key belongs, webhooks accepted without verifying the signature, and amounts or entitlements trusted from the browser.

  • Framework-specific mistakes

    Rule packs for Next.js, Node and Express, Laravel, Django, Supabase and Firebase — the places where each one makes a particular mistake easy to make.

See what each check looks for, and what it cannot see

What a finding looks like

The explanation comes first. The vocabulary comes second.

Every finding leads with what could happen and to whom, then shows the code it is based on and the steps to fix it.
  • Severity and confidence are always both shown, so "we are fairly sure" never reads as "we confirmed it".
  • Evidence is the actual matched code, not a paraphrase of it.
  • Remediation is specific to the pattern found, not a link to a general article.
  • The technical name is there for whoever wants it, one click down.
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.

Why this matters now

Building faster did not make the security work smaller

Tools like Cursor, Claude, Lovable, Bolt and Replit removed the slow part of shipping software. They did not remove the review that used to happen while you were being slow.
  1. The code works, so it looks finished

    Generated code is usually correct about the thing you asked for. Nobody asked it to check that the person requesting a record is allowed to see it, so nothing about the result looks wrong — and there is no compiler error for a missing permission check.

  2. The gaps are the boring parts

    Authorization on every endpoint, webhook signatures, cookie flags, a secret that never reaches the client. Unglamorous work, easy to skip when you are moving quickly, and where most real incidents start.

  3. A second reviewer is normal engineering practice

    Teams have code review because the person who wrote something is the worst placed to spot what they left out. Building alone, or building fast, does not remove that need. It removes the reviewer.

What we will not claim

  • We will not tell you your application is 100% secure. Nobody can honestly make that guarantee.
  • Automated scans cannot replace human intent verification or business-logic threat modeling.
  • A clean scan means the checks we executed passed without incident, with exact telemetry reported.

Who it is for

Three audiences, one product

Plans and quotas live in the pricing catalogue. This is only what each person does with Audixa.
  1. Builders shipping with AI

    The code works, so it looks finished. Audixa reviews secrets, permissions and live configuration so the next step is not an incident.

  2. Developers and product teams

    A second reviewer over the repository and the domain. Findings with evidence, not a generic report nobody applies.

  3. Agencies

    The same review on every delivery. The client sees the evidence; you see what is still open before you call the project done.

Pricing

Start free on one project

Paid plans raise the number of projects and scans, add checks against your live domain, and unlock finding titles, evidence and how to fix them.

Free

Review one project before you launch it.

Free

No credit card required. No expiring trial.

Projects
1
Scans a month
1
Concurrent scans
1
Seats
2
AI Fix tokens
0
  • One project, one scan a month
  • Secret, dependency and static-pattern checks on a connected repository
  • How many findings there are, and how severe they are
  • Findings history, so you can see whether a fix held
  • Copy-paste AI prompt for selected findings
  • Finding titles, evidence and remediation steps, which unlock on a paid plan
  • Checks against a live domain, which require domain verification and a paid plan
Recommended for most teams5 projects

Pro

For a founder or freelancer shipping continuously.

€29per month

Excluding VAT, which is added at checkout.

Projects
5
Scans a month
30
Concurrent scans
3
Seats
5
AI Fix tokens
50
  • Five projects, thirty scans a month
  • Finding titles, evidence, file locations and how to fix each one
  • Everything in Free, plus checks against your verified production domain
  • TLS, security header, cookie, CORS and redirect configuration checks
  • Scan comparison: what is new, what persists, what regressed
  • Shareable in-app reports
  • 50 AI Fix tokens a month. A dependency fix costs 2; a larger code change costs more (never auto-merged)

Agency

For a team reviewing work across several clients.

€99per month

Excluding VAT, which is added at checkout.

Projects
25
Scans a month
150
Concurrent scans
5
Seats
Unlimited
AI Fix tokens
250
  • Twenty-five projects, a hundred and fifty scans a month
  • Everything in Pro, with unlimited seats
  • 250 AI Fix tokens a month. A dependency fix costs 2; a larger code change costs more (never auto-merged)
  • Reports you can put your own name on
  • Priority support by email
  • Separate client workspaces are on the roadmap, not in the plan today. See the agencies page.
Compare the plans in full

Professional services

Prefer us to handle it for you?

A landing, a small site, or custom web or app work. The product is the security review; this is what we do when you want us to build, fix, or keep something running.

Landing

One page that looks finished and can take enquiries.

€299one-off

Excluding VAT, which is added at checkout.

  • A single responsive page, tested on a phone as well as a laptop
  • A contact form that reaches your inbox
  • HTTPS, security headers and deployment on a host in your name
  • Basic technical SEO: title, description, sitemap and OpenGraph
  • Extra layouts, logins, a CMS or a shop — those are a different package or custom work
Most sites start here

Business site

A small brochure site with a handful of pages, not an application.

€490one-off

Excluding VAT, which is added at checkout.

  • Up to five distinct pages (for example home, about, services, contact, legal)
  • Everything in Landing, including the contact form and deployment
  • Two rounds of changes on a real preview URL
  • A short handover on how to change the text
  • User accounts, payments, or anything that needs a database — that is custom work

Custom web or app

A product with logins, data or a store listing — scoped before it is priced.

Quoted

Fixed price after we have seen the scope. No checkout from this page.

  • A written scope and a fixed price per phase, after a conversation
  • Web application or mobile app, with the repository and hosting in your accounts
  • Authorization and a security review before launch, not as an add-on
  • Handover designed so another developer can take over without calling us
  • No price from this page: an estimate before we have seen the data model would be fiction
See all services

For agencies

A repeatable review you can run on everything you deliver

Run the same checks across the work you hand over, show a client the evidence rather than your word, and catch the dependency that went stale on a site you built eighteen months ago.
How agencies use Audixa

On the roadmap, not in the plan today

Separate client workspaces, with their own members and their own reports, are something we intend to build. They are not in the Agency plan yet, and we would rather say so here than let you find out after paying for it.

Questions

The things people ask before signing up

Do you run my code?

No. We read your repository and parse your lockfile; we never install dependencies, run a build, or execute a script from your project. Analysis happens in a throwaway container with networking switched off, and the workspace is destroyed when the scan ends.

Do you keep my source code?

No. What survives a scan is the findings and up to three lines of context around each match, with anything that looks like a secret redacted before it is stored. The copy of your repository is deleted when the job finishes, whether it succeeded or failed.

Will you tell me my app is secure?

Never, because nobody can. A scan with no findings means the checks we ran did not find anything, and we show you exactly which checks ran and which did not. That is a useful answer; "you are secure" would not be.

Does this mean AI-built software is insecure?

No. AI-assisted code is not inherently worse than code written by hand — it is written faster, which means less of it gets reviewed. Audixa is a review layer, not a verdict on how the code was produced.

Can you scan a live site without access to the repository?

Partly. We can check the configuration your domain serves — certificates, security headers, cookies, CORS, redirects — once you have proved you control that domain. Finding a hard-coded secret or a missing permission check needs the code.

Do you use AI, and does my code go to an AI provider?

AI explains findings in plain language and suggests remediation. It cannot create a finding: those come from scanners with evidence attached, and the database enforces that rather than trusting us to remember. When AI is enabled we send only the few lines a finding points at, with detected secrets removed first, and you can turn it off for your whole organization.

Will you change my code or open pull requests?

Only when you ask. You can copy a prompt and apply the diff yourself, or ask Audixa to open an AI Fix pull request or a verify-badge pull request. Those branches are never merged automatically. Scan clones stay read-only.

What happens if I need someone to actually do the fixing?

You can ask us. Remediation is one of the services we offer, and a request started from a finding arrives with the project, scan and finding already attached. It is priced per piece of work after we have looked at it, not from a rate card.

Find out what a review of your project turns up

Connect a repository, run one scan, and read the findings. If there is nothing to fix, you will know which checks said so.

Start scanning freeOr read what happens during a scan

Start free. No automatic changes to your code.