Security audit

Your booking system works. Is it still secure?

AI now finds flaws in software faster than teams can fix them, including in systems that have run without trouble for years. We scan your booking flow with dedicated security models and send you every confirmed finding, with the fix. Free.

Outside-in only: we need the address of your booking page, not your code.

booking.example-clinic.com

Outside-in scan, finished

Example
1,284
Paths followed
19
Suspected
4
Confirmed
  • HighBooking readable by its number/booking/10482
  • HighDeposit amount set by the browserPOST /api/checkout
  • MediumNo limit on SMS code requestsPOST /api/verify
  • LowCalendar file shows client phone/ics/appointment
An example of the report: each confirmed finding comes with the steps that show it and the fix.
Price, no card, no obligation
$0
All we need: your booking page
1 URL
Load tests or data changes
0
To your report, minutes once the scanner is out
Days

Why audit a system that has worked for years?

Because the people looking for its weak spots got new tools. Working without trouble says nothing about what nobody has looked for yet.

  • AI finds flaws faster than before

    Agents built on language models read code and probe web apps around the clock, at almost no cost. Old flaws that nobody had time to find are now cheap to find, for attackers too.

  • Booking systems are an easy target

    A public page anyone can use without an account, names, phone numbers and health or visit details behind it, and often a payment or deposit step. That is what attackers look for.

  • Stable often means unpatched

    A system nobody has touched in years runs on plugins, libraries and settings from years ago. Each of them may have a known flaw published since.

What does the audit look at?

The booking flow as an attacker sees it: everything your customers can reach from the internet, without an account or with a customer's one.

  • Other people's bookings

    Can a booking reference, link or ID be guessed to read, change or cancel someone else's appointment?

  • Personal data leaks

    Names, phone numbers or notes exposed in confirmation pages, calendar files, emails or API responses.

  • Payments and deposits

    Can a price, a deposit or a voucher be changed on the way, or a slot booked without paying?

  • Bots and abuse

    Can slots be blocked in bulk, codes sent in a loop, or forms flooded? Are there limits on how often?

  • Sign-in and sessions

    Customer and staff sign-in, password reset, one-time codes and how long a session lives.

  • Injection in forms

    Fields and parameters that let code or queries through: notes, names, search and filters.

  • Exposed API and admin

    Endpoints, admin panels, backups and debug pages reachable from the internet that should not be.

  • Outdated components

    Plugins, libraries and server software with known, published flaws.

  • Transport and headers

    TLS, security headers, cookies and the rules that keep your page from being framed or scripted by another site.

How does the audit run?

Many small, fast scans instead of one slow one: the models follow far more paths through your booking flow than a person could in the same time.

  1. 01

    Send the address

    Sign in and give us the address of your booking page, what it runs on and who you are.

  2. 02

    We confirm you may test it

    We only scan a system you own or are allowed to have tested. If that is not obvious from the address, we write to you first.

  3. 03

    Dedicated models scan it

    Our scanning runs many security model calls across the booking paths, then checks each suspected flaw again so the report holds confirmed findings, not guesses.

  4. 04

    You get the report

    Every confirmed finding, how serious it is, how we found it and how to fix it, by email. A person on our team reads it before it goes out.

Ground rules

How do we keep the audit safe?

A security test that breaks something is not a test. These rules hold for every audit.

  • Only with permission

    You confirm you own the system or are authorised to have it tested, and we check before any scan starts.

  • Nothing destructive

    No load tests, no denial of service, no real bookings left behind, no data changed or deleted.

  • Outside-in only

    We test what is public. We never ask for your code, server access or passwords.

  • The report is yours alone

    It goes only to the email you signed in with. We never publish or share findings.

  • A person signs off

    The models scan; a person on our team reviews the findings before you see them.

  • No strings attached

    Fix the findings yourself, with your current vendor or with us. The audit is free either way.

Why is the audit free?

Our scanning runs on fast, efficient models, so one audit costs us little. And a booking system with a hole in it is often the start of a conversation about a better one.

If the report shows more than a few quick fixes, we can fix them for you, or build you a booking system of your own at one fixed price. That is an offer, not a condition.

What we build →Pricing →

Check your booking system

Sign in with your work email and send the address. The online scanner you can run yourself is coming soon; until then, our team runs each audit.

Coming soon: run the scan yourself, online, and watch the findings come in.

What do people ask about the audit?

Is the audit really free?
Do you need our code or server access?
Can the scan break our system?
Can I ask you to audit someone else's system?
What are the scans built on?
How long does it take?
What is in the report?
Does it work for any booking system?
Who fixes what you find?