Security and data

Not yet. Validiscan’s application, with a console where Validiscan does the work and a portal for customers, is built but not in operation: its address, app.validiscan.com, is not online.

This page describes how the application is built and set up as of 6 October 2026. Where a part is not set up yet, the page says so.

Validiscan’s application stores its database, its user accounts and its files with Supabase, in Supabase’s Frankfurt region (eu-central-1). Supabase is a US company; the data itself is stored in Frankfurt. Storage is in the EU, but not everything stays there: when AI drafting is switched on for a shop, an excerpt of the failing code goes to Anthropic, a US company, as described below.

The files are screenshots of scanned pages, page HTML, raw test results, evidence packages, patch bundles, theme exports uploaded in the portal, and files Validiscan attaches as evidence of its manual checks. They are kept in private storage with no public links. The application creates a link to a file only at the moment someone with access opens or downloads it, and the link stops working after 60 seconds.

The fixes themselves end up on your own platform: as a pull request in your GitHub repository, or as an unpublished copy of your theme in your Shopify store. A patch bundle is kept in the application’s storage, and Validiscan sends it to your developer.

In Validiscan’s application, each customer sees only the data of its own organization. Validiscan’s staff see all projects; today that is one person, William Quaade Rasmussen.

• Enforced in the database. Every table of the application has row-level security: the database itself decides which rows an account may read, not only the pages of the application. Automated database tests check that one customer cannot read another customer’s data.
• Two roles for customers. In a customer’s organization, an admin can invite colleagues and ask for a verification scan. A viewer can see the organization’s data in the portal but change nothing.
• Access tokens are encrypted. A Shopify Theme Access password, a GitHub token or the password of a protected staging shop is encrypted with AES-256-GCM before it is stored. The application shows only that a token exists. No account in the application can read it back, a staff account included; only the application’s background worker decrypts it, when a job uses it.
• A record of every change. Every change a user makes in the application is written to an audit log, with who made it and when. Only Validiscan’s staff can read the audit log.
• Logs without secrets. The application’s logs leave out passwords, tokens, keys, cookies and request bodies.

Validiscan’s application uses AI only to draft fixes of tier ASSISTED, and only on a shop where AI drafting is switched on. It is off by default. Validiscan switches it on for a shop only after the customer has agreed in writing, and only Validiscan’s staff can change the setting. Even then, the application drafts nothing with AI on its own after a scan: each draft is requested by Validiscan for a specific finding.

A draft is written by a model of Anthropic (Anthropic PBC, a US company), through Anthropic’s API. For each draft, the application sends:

1. the rule that fails: its id, title, impact and WCAG success criteria, and the shop’s platform;
2. the rule catalogue’s advice on how to fix it;
3. up to five failing elements, each with its CSS selector, the failure summary, its HTML as rendered (at most 2,000 characters) and the path and template of its page, but not the page’s full address;
4. the path of the theme file the failure was traced to, and up to 200 numbered lines of that file around the code it was traced to.

The application sends no screenshots, no passwords or tokens, no customer or account data, and nothing from other shops. An element’s HTML can still contain your shop’s own links or visible text.

What comes back is a proposed change with an explanation. The application rejects a draft that changes any file other than the one it was shown, creates or deletes a file, or whose diff is longer than 400 lines, and it checks that the change applies cleanly and passes a syntax check. A draft that fails these checks is never delivered. Validiscan reviews every draft before delivery, and you or your developer review the change again before you merge or publish it.

By default, Validiscan’s application deletes the screenshots, page HTML and raw test results of a scan 365 days after the page was scanned, unless an evidence package is built from that scan. Project records are not deleted automatically.

How long project records are kept after a project ends is not settled yet. You can ask Validiscan to delete them, or a stored access token, by writing to info@validiscan.com. On Shopify you can also end the access yourself: as of 6 October 2026, Shopify’s documentation says that deleting the password in the Theme Access app revokes the access. The database is backed up every day and each backup is kept for 7 days, so data deleted from the database can remain in a backup for up to 7 days.

For a free check, ValidiscanBot loads at most 15 public pages of the shop in its browser, each at desktop size and at phone size. To choose those pages it first makes plain requests for the home page, robots.txt, sitemaps and candidate pages, so it makes more requests than it loads pages. It follows the shop’s robots.txt and leaves a gap of at least 1 s between the requests it starts itself, with one known exception described below. The files a page loads itself, such as styles, scripts and images, load as in any browser. It never signs in, never adds a product to a cart, never opens the checkout and sends no forms.

• It names itself. Every request carries ValidiscanBot/1.0 (+https://validiscan.com; info@validiscan.com). In the phone-size pass the same string ends in the word Mobile.
• It reads robots.txt before the other pages. Its first request is for the home page, to see whether the shop answers. Then it reads robots.txt. If robots.txt disallows the home page for ValidiscanBot, or the server answers the request for it with a server error (5xx), with 429 (too many requests) or not at all, the check stops there.
• It waits longer if robots.txt asks. A longer Crawl-delay in robots.txt is followed, up to 10 s.
• One known exception. When the shop answers a page load in the browser with a redirect, the browser follows it at once, without the gap and without checking robots.txt. Validiscan has recorded this as a known gap in its scanner.
• It reads only what is public. Personal data reaches the scan only where the shop’s public pages show it, for example a name in a product review or in the imprint.

When the application runs a free check, it keeps a summary: the number of pages tested and of failures by impact, the platform and any accessibility overlay it detected, and up to five failures, each with the rule, a page address, the CSS selector and the failing element’s HTML, cut to 300 characters. The summary is not deleted automatically. The raw result keeps the findings with their page addresses and element HTML, but no page HTML, screenshots or raw test output; by default it is deleted 365 days after the check.

Validiscan’s application starts a full scan of a shop only when the shop owner’s permission is recorded. A full scan goes further than the free check: it adds one product to the cart and opens the first checkout step, without completing a purchase and without entering payment data.

Validiscan records the permission in the application, with the time and the name of the person at Validiscan who recorded it. Without a recorded permission, no full scan starts, the portal refuses a request for a verification scan, and regression protection skips its run. To withdraw the permission, write to Validiscan.

Write to info@validiscan.com. The email reaches William Quaade Rasmussen, who runs Validiscan. What this website itself does with personal data is in the privacy notice for validiscan.com.