Website security check for your own web app: four layers, what each scanner proves, and the tests to run by hand

Before you pay for a scanner, run a website security check logged in as a real user: a free online checker reads your headers and TLS, while an authenticated scan and a few hand-run tests reach the app itself. Of the 21 third-party apps I audited in June and July 2026, 11 had unauthenticated endpoints doing privileged work.

What a website security check is: four layers, and what each one proves

A website security check has four layers: a surface scan of headers, TLS and known software; an authenticated scan by a tool logged in as a user; discovery of what is exposed; and test cases run by hand. Free online checkers run the first, logged out. The hand cases settle whether one customer can open another customer’s data.

That 11 comes from a selected set: the 21 third-party apps I audited, picked for review rather than drawn at random, so it tells you where to look, not how often AI-built apps in general leave a route open. This page is the how-to-check half of web app security: the controls are described there, and the ways to test them are here.

The table below is how I split the work. The “proves” and “misses” columns are my reading of what each layer can and cannot see, not a vendor’s claim, and the time column is my working rule for a small app with one login.

Row one is the online web security scan every free checker runs, and it is worth running first: a missing header or an expired certificate is a real finding. A website security test that stops at row one has tested the web server’s front, not the app behind the login. To check a website for vulnerabilities that matter, you have to scan and test it while signed in as a customer, because that is where the data is. If you are a beginner at web application security testing, start with row one: it needs no account.

NIST’s definition of a vulnerability assessment is a “Systematic examination of an information system or product to determine the adequacy of security measures, identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures, and confirm the adequacy of such measures after implementation.” Aimed at one web app, that becomes an application vulnerability assessment: the same examination, pointed at the software you ship and tested with real requests rather than read off a checklist. A VA scan is the automated share of it; in my reading of the term, that means the first two rows of the table. NIST’s definition of security testing is shorter: “Testing that attempts to verify that an implementation protects data and maintains functionality as intended.” IT security testing in general also covers networks, laptops and internal systems; for one web app it narrows to these four layers.

To conduct a vulnerability assessment on your own app, run the four layers in order and keep what each one produces; the order is set out under the how-to-run heading below. If you need a site security assessment template, copy the table and add a result column; there is nothing to download. Run in order, the four layers are a web security assessment sized for a small app, and they test the app’s security from the outside in. If you are working out how to security audit a website, or asking an assistant to “help me write a web security audit”, the same table is the outline: every finding then names the layer that caught it. The five scanners worth comparing for AI-built apps are covered in vibe coding security scanners compared.

Why it matters: what a surface scan cannot see

A clean surface scan and a safe app are different results. The checks that matter most sit behind the login, where a logged-out online checker does not reach: whose records a user can open, which routes need a role, and what the server does with a request it should refuse.

In the same June and July 2026 audits, 7 of the 21 third-party apps had confirmed cross-user or cross-tenant authorization failures, where a logged-in user could read or write another customer’s data. Across all 26 apps I audited, 9 ran a framework version with a publicly known, reachable RCE or auth bypass, and the fix was usually a one-line version bump. Neither count is a rate for AI-built apps as a whole: both come from the apps I chose to audit, a selected group of 21 and 26 rather than a sample. The second one is the dependency layer, which a dependency audit settles.

Why a scanner’s list of advisories differs from a list of reachable findings is told, with numbers, in what a scanner proves about your app, and what it cannot.

Picture a founder who runs a free online website security check on the app’s home page and gets back a clean report on the headers, TLS certificate and software versions the checker reads from outside. One of the API routes the app’s pages call does privileged work and answers a request that carries no session at all, and the checker read the home page and never sent that route a request. The report graded what the checker read, not what each route does with a caller it should refuse, and a logged-out request to each privileged route is a hand case, not a scan result.

Scan only what you own or have written permission to test. In the UK, section 1 of the Computer Misuse Act 1990 makes it an offense to cause a computer to perform a function with intent to secure access to a program or data, where that access is unauthorized and the person knows it is. In the US, 18 U.S.C. 1030 makes it a federal offense to intentionally access a computer without authorization, or exceed authorized access, and thereby obtain information from a protected computer. Whether a given scan falls under either depends on the country and the facts, and this is not legal advice.

How to run a website security assessment, layer by layer

A website security assessment runs the layers in order: discovery, then the authenticated scan against staging, then fuzzing on the input endpoints, then the ten hand cases. Keep the export from each layer. A scan result is a list of questions until a person confirms each one.

The tool behavior below comes from each project’s own documentation, not from tests I ran. The seven parts are in the order you would run them, with the two reading sections (tool lists and free checkers) at the end.

Discovery: nmap, subdomains and what is exposed

Nmap lists the open ports on a host and the software behind them. On a managed host those ports belong to the provider, so the useful discovery for a small app is subdomains and forgotten hosts, such as a staging URL that still points at production data.

nmap’s reference guide describes it as “an open source tool for network exploration and security auditing”, which is the plain answer to what nmap is in cyber security: a network mapping tool that shows which ports answer and, with version detection, which software sits behind each one. As a port scanning tool, nmap turns on service and version detection with -sV, and you can check UDP ports as well with -sU. Like most of nmap’s scan types, the UDP scan needs a privileged user (root on Unix) because it sends and receives raw packets; of the scan types on that page, unprivileged users can only execute connect and FTP bounce scans. Against your own staging host, the nmap scan is one line:

nmap -sV staging.example.com

Used as a penetration testing tool against your own host, nmap answers one question: what is reachable from outside. On Vercel, Supabase or Railway the open ports are the provider’s, so a port list tells you little about your app. The useful output is your subdomain list: every host name that points at something of yours, including the ones nobody remembers creating. For subdomain enumeration, the first tool is a public record: with certificate transparency, domain owners can see “which CAs have issued which certificates, when, and for which domains”, in logs it calls “publicly verifiable, append-only, and tamper-proof”. Interactsh (interact.sh) and other out-of-band tools belong to a tester confirming a blind callback; Interactsh’s own repository calls it “an open-source tool for detecting out-of-band interactions”, and a founder checking one app can leave it alone. Discovery proves what is reachable from outside and says nothing about what happens behind the login.

The scanners: ZAP, Burp and what each one finds

ZAP is free and open source and can run in CI through its automation framework. Burp Suite Community is free for the proxy and manual tools, and Professional adds the scanner. ZAP’s scan rules look for injection and missing headers, and neither tool knows which user should see which record.

OWASP ZAP is a DAST tool: it tests the running app from outside, passively scanning the traffic it proxies and actively scanning, which its docs describe as “using known attacks against the selected targets”. Its site now reads “ZAP by Checkmarx” and calls it “an independent Open Source project”. It logs in by the methods its authentication docs list, among them form-based, JSON-based, HTTP/NTLM and script-based authentication, and its Authentication Helper add-on adds browser-based and client script authentication, which the automation framework also supports. ZAP automation works from one YAML plan file (the docs say the framework “allows you to control ZAP via one YAML file”), and the Docker image runs that plan in a CI job, which for a small app is the ZAP integration to set up first:

docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable zap.sh -cmd -autorun /zap/wrk/zap.yaml

The plan file names the target, the login and the jobs, such as the spider, the active scan and the report. Run from the command line, the framework exits with 0 when the plan ran without problems, 1 on an error and 2 on warnings, so a CI step can fail on the result. For open source pen testing of your own app, a ZAP scanner run against staging is the first step; how that differs from reading the code is SAST vs DAST.

Burp Suite is PortSwigger’s web testing toolkit, and what it does depends on the edition. Community is free: its download page lists the HTTP(s) and WebSockets proxy and history, Repeater, Decoder, Sequencer and Comparer, and Burp Intruder as a demo. Burp Suite Professional is paid and adds the web vulnerability scanner, the full version of Burp Intruder for custom attacks, automatic crawling and out-of-band testing. For a founder, Burp Suite is used for one thing first: its proxy shows what your app actually sends and receives, request by request. Web application security testing with Burp Suite is still penetration testing work, with a person deciding what to try next. Caido is a Burp Suite alternative that describes itself as “The web hacking toolkit designed to scale manual testing through AI and teamwork”; its Basic plan is “free forever”, and it is not open source.

In a comparison of OWASP ZAP and Burp Suite for one small app, the deciding line is the scanner: ZAP’s is free, and Burp Suite’s is in the paid edition. Of the open source security tools on this page, ZAP and, for discovery, nmap are the penetration testing tools I’d start a small app with, while Burp Community and Caido Basic are free to use.

In my reading, an automated scan by either tool is good at reflected injection, missing headers and other known patterns, and blind to the business rule about which user may see which record. As the OWASP Web Security Testing Guide’s introduction puts it, automated tools are “necessary and valuable, but they are insufficient on their own”, and they “excel at finding known, signature-based vulnerabilities; they do not understand business logic or context.” Against the OWASP Top 10, Burp Suite’s scanner and ZAP cover some categories, and the hand cases below cover the rest, starting with broken access control, which ZAP’s own docs say “will not be found by any active or automated vulnerability scanning”. A security scan that only reads the website from outside is row one of the table: the free online checkers are web-based scanners, and their scanning happens from outside, with no account. The comparison of five scanners for AI-built apps is the article linked in the first section.

Fuzzing: what it is, and the one place a small app needs it

Fuzzing automatically feeds a program unexpected, malformed or semi-malformed inputs to find bugs, vulnerabilities or unexpected behavior. A small web app needs it in one place: the endpoints that take uploads, search terms and imports. Engine and protocol fuzzers are built for other targets.

That definition comes from OWASP’s page on fuzzing, and it is what fuzzing means in cyber security generally, not only on the web. On a small app, web fuzz testing means sending junk to the parameters and paths of your own upload, search and import endpoints, to see whether the input layer holds. The fuzz testing tools for that job are ffuf, a “Fast web fuzzer written in Go” released under the MIT license, and ZAP’s own fuzzer, which “allows you to fuzz any request”. I print no command or wordlist here: point either tool only at endpoints you own. Application fuzzing of engines and protocols is a different job: Fuzzilli calls itself “A JavaScript Engine Fuzzer”, and GitLab’s protocol fuzzing framework is based on Peach Fuzzer Professional. Website fuzzing proves that the input layer holds under junk, and it does not test logic, so a fuzzer will never tell you that user B can read user A’s invoice.

Scanning an API rather than a web page

An API has no pages to crawl, so an API security scan needs the API description (an OpenAPI file) or a recorded session to know what to call. ZAP’s OpenAPI add-on imports OpenAPI definitions, versions 1.2, 2.0, 3.0 and 3.1, and can import them as a logged-in user, which makes ZAP the plainest API security scanner for a small REST backend. ZAP, itself open source, covers a REST API this way; a GraphQL API has security testing tools of its own: graphql-cop, “a small Python utility to run common security tests against GraphQL APIs”, and InQL, “a robust, open-source Burp Suite extension for advanced GraphQL testing”. Whichever of the API testing tools your team already uses for QA, Postman or Bruno, is the best place to keep the security cases below as a saved collection; it runs the requests you wrote, nothing more. The full API security assessment is its own checklist, including how to capture a request in the browser and replay it as a second account.

The ten test cases to run by hand, and how to automate them

Ten hand-run cases test what no scanner decides for you: another user’s record, an admin route as a normal user, a logged-out request, a quote in a search box, a burst on the expensive endpoint, a bad upload, a foreign origin, the headers, an unsigned webhook, and an instruction hidden in user text.

Run them against your own staging copy with two test accounts, A and B. Each security test case below is written as an example you can copy: what to send, what should come back, and what to keep. Treat the list as my working security test guide for a small app, not a standard.

1. 01 As user B, request user A's record by its id, with B's own session cookie or token in place of A's. Expect 403 or 404, never A's data. Keep the status line and the response body, dated.
2. 02 As a normal user, open an admin route. Expect 403. Keep the status line and the response body, dated.
3. 03 Logged out, request a URL that needs a login. Expect 401 for an API call, or a redirect to the login page for a page route. Keep the status line and the response body, dated.
4. 04 Type a single quote into a search field. Expect ordinary results or a validation message, never a database error. Keep the response, dated.
5. 05 Send a burst to your most expensive endpoint, about 200 requests in a minute, set above your real limit. Expect 429 once the limit is reached and the requests after that refused, though on an edge rule excess requests may still get through first. Keep the count that got through, dated.
6. 06 Upload a file with a disallowed extension, then one over the size limit. Expect both refused. Keep both responses, dated.
7. 07 From another origin, send a request with credentials. Expect no Access-Control-Allow-Origin header naming that origin. Keep the response headers, dated.
8. 08 Read the response headers of any page. Expect Strict-Transport-Security and a Content-Security-Policy header. Keep the header list, dated.
9. 09 Send your webhook endpoint an event with the signature header removed. Expect it rejected. Keep the status line, dated.
10. 10 Put an instruction inside ordinary user text that reaches the AI feature. Expect the feature to treat it as text. Keep the input and the output, dated.

Where the browser reads the database directly and row level security guards the table, as in a Supabase app, a refused read in the first three cases comes back as an empty result, not a 401, 403 or 404, and that empty result is a pass. PostgreSQL’s manual says that with no policy “no rows are visible or can be modified”, and rows a policy does not allow “will not be processed”; A’s data in the reply is the only fail. The slack on an edge rule is Cloudflare’s own: its rate limiting rules “are not designed to allow a precise number of requests to reach your origin server”, and there “may be a delay of up to a few seconds” before the counters update.

The status codes mean what RFC 9110 says: 401 when a request “lacks valid authentication credentials”, 403 when the server “understood the request but refuses to fulfill it”, and 404 when it will not disclose that the record exists; RFC 6585 defines 429 as “too many requests in a given amount of time”. MDN on Access-Control-Allow-Origin explains that the header decides “whether the response can be shared with requesting code from the given origin”; Strict-Transport-Security tells browsers to use HTTPS only, and Content-Security-Policy controls which resources a page may load. What belongs in those last two headers is a subject of its own.

The quote in the search box is the smallest check covered in SQL injection prevention, the burst is the test behind rate limiting in API routes, and the hidden instruction is explained in what is prompt injection. Capturing a request in the browser and replaying it as the second account is explained in the API checklist linked in the section above, so it is not repeated here. For a founder without a script, the no-code versions of the second-account and logged-out checks are in how to check an AI-built app yourself.

To automate security testing, make each case one test in your smoke suite (see how to write end to end smoke tests), and let ZAP’s automation framework run the scan in CI. That setup is what automated pen testing amounts to for a small app, and it is not a pen test. Automated penetration testing repeats known checks on every build, while a tester thinks about your business rules, which is what web application penetration testing buys. The same cases written as instructions for your builder are in nine prompts that change what your AI builder writes.

Pen testing tool lists, and why a list is not a test

Lists of penetration testing tools rank tools, and a tool proves nothing until it runs against your app, logged in, and someone reads the result. A top 10 of pentest tools or of vulnerability scanning tools gives a line per product and no method, and none of those products has run against your app yet.

For a small app, the honest inventory is four tools: nmap, ZAP or Burp Community, ffuf, and a dependency audit such as the npm audit command. Nmap, ZAP, Burp Community and ffuf cost nothing, and of those, ZAP is the free vulnerability scanner that crawls and attacks a logged-in app. Those four are the best vulnerability assessment tools to start with on a small app, because together they reach discovery, the logged-in scan, the input endpoints and the dependencies. The pen testing tools that are open source among them are nmap, ZAP and ffuf. Any web security testing tool you add later should answer one question first: which layer of the table does it cover? Before paying for website security testing software, run these four free tools and see which layer is still uncovered.

Two other kinds of list sit next to these: static code analysis tools, which read the code instead of the running app, and vulnerability management tools, which track findings over time. Enterprise network scanners such as Nessus and OpenVAS are aimed, as I read them, at estates of many machines rather than one web app. If you would rather buy a test than run one, start with affordable penetration testing.

Website hack testing: what a free online checker sees, and what it cannot

Website hack testing with a free online checker answers whether the front door is painted, not whether it is locked. The checker reads headers, TLS, known software and malware or blacklist status from outside. Whether your app is hackable takes the logged-in scan and the ten hand cases.

The checkers on the first page of results describe their own reach. One checks for “known malware, viruses, blacklisting status, website errors, out-of-date software, and malicious code” and adds that “Remote scanners have limited access and results are not guaranteed”; another analyzes “HTTP headers, SSL certificate and DNS configuration”; a third scores “HTTP headers, TLS and SSL, DNS, cookies, and CSP”. A website security checker of this kind works without an account. Whether it calls itself a website hack checker, a website vulnerability scanner or an online vulnerability scanner, it can only scan the pages anyone can load, so it never sees the pages and API routes where one customer’s data sits next to another’s; a real app hack check starts where it stops. A free website security scan is still step one of the five below, because it is quick. Give a web security scanner a test account and it can scan for vulnerabilities behind the login, which is the authenticated layer above.

Two other questions sound similar. Whether someone else’s site is safe to visit (Google Safe Browsing, site-trust checkers) is a visitor’s question, and whether your own site was already broken into is answered in how to tell whether your app was hacked. To scan a site for vulnerabilities that matter to your customers, run the four layers above; their tools are free, as the tool-list section says.

How can I test the security of my website? The five steps, in order

Testing your own website’s security takes five steps in order: a surface scan, a dependency audit, an authenticated ZAP scan against staging, the ten hand cases with results written down, then one page recording what ran, what was found, what was fixed and the date. That page plus the scan export is the evidence.

1. 01 Run one free online checker against your production domain. Keep its report with the date.
2. 02 Run the dependency audit for your package manager. Keep the output.
3. 03 Run an authenticated ZAP scan against staging. Keep the export and one line proving the scan stayed logged in.
4. 04 Run the ten hand cases. Write down the status line and the body of each response.
5. 05 Write the one-page record: the four layers, what ran, what was found, what was fixed, and the date.

The dependency audit is the npm audit step from the tool-list section. The one line of logged-in proof is covered in the scanner article linked in the first section, under “Authenticated scanning has to prove it stayed logged in”. As I see it, that one page plus the scan export is what a customer’s security reviewer can read and check. My working rule is to re-run all five after every release that touches login, roles or uploads.

Where the sprint does this

In the Production Hardening Sprint, we review the application against the OWASP Top 10 and record findings, fixes, and evidence by category, and deliverable 3.7 is verified this way: deliver category-level results and supporting test evidence, with justified non-applicable cases identified. We test the five highest-risk externally reachable attack surfaces, remediate findings, and deliver the methods and evidence; deliverable 3.10 is verified by recording the five surfaces, authorized tests, findings, fixes, and retest outcomes, and AxonBuild performs this targeted test. We audit dependencies, upgrade or remove known-vulnerable packages, and remove unused packages, and deliverable 3.5 is verified by recording the dependency scan, remediation, and regression checks after changes. Every item lands in the production readiness report (13.1), which accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items. Formal third-party certifications and independent audit opinions are separate from these deliverables. The full list is in the security deliverables in the published scope.

Common questions about testing your own site’s security

Is vulnerability scanning illegal?

Scanning your own app, or one you have written permission to test, is the normal case; the permission decides it, not the tool, and that holds for ZAP, Burp and nmap alike. Without permission, UK law makes it an offense to cause a computer to perform a function aiming at access you know is unauthorized (Computer Misuse Act 1990, section 1), and US federal law covers access without authorization in 18 U.S.C. 1030. ZAP’s own docs say of its active scan: “You should NOT use it on web applications that you do not own.”

Is OWASP ZAP still used?

Yes, and it is still maintained: the download page offers ZAP 2.17.0, whose GitHub release is dated December 15, 2025, and weekly releases are built from the main branch, “typically every Monday”. The project’s site footer credits Checkmarx. I make no claim about how many teams use it.

What are the four stages of vulnerability assessment?

In the way I run it, the four stages are: find what is exposed, scan the app logged in, confirm each finding with a direct request, then fix and retest. That is my mapping onto the layers on this page, not a list any standard publishes.

What is better than Burp Suite?

For one small app, nothing needs to be: ZAP, or Burp Suite Community, plus the ten hand cases covers what a tool can, and the scanner in Burp Suite Professional is the paid step up. Caido is the other option with a free plan, called Basic, and it is not open source.

Is there a free vulnerability scanner?

Yes. ZAP is free and open source, nmap is free to use under its own license, Burp Suite Community is free (the scanner sits in Professional), and ffuf is MIT-licensed. The free online checkers cost nothing too, and they describe outside checks of headers, TLS, software versions, and malware or blacklist status.

What is the best website scanner?

No scanner is best at every layer: a free online checker covers the surface, a logged-in DAST scan such as ZAP covers the app, and hand-run cases cover authorization, which automated scanning does not find. The five-scanner comparison for AI-built apps is the scanner article linked near the top of this page.