On the night of September 3 to 4, 2026, Communauto detected unusual activity in its systems. An employee had launched an automated script to view and download customer files: names, dates of birth, addresses, driver’s licence numbers. Access was cut off during the night and the police were notified. According to the company, nothing indicates that the data was distributed.

Whatever the state of Communauto’s website, no surface scan would have answered the real question. How many files can a signed-in account extract? Does anyone see it when it happens?

That is the difference between looking at your site from the outside and testing it in depth. Both are useful. They do not answer the same question, though, and the order matters.

What a surface scan sees

A surface scan looks at what anyone can see from the outside, without signing in. That is what the free tool loi25.certi360.com, which we built at Certi360, does. In a few minutes, it checks:

  • domain and email configuration (SPF, to limit spoofing of your addresses);
  • HTTPS encryption and certificate validity;
  • security headers, such as HSTS (force HTTPS) and CSP (limit which scripts can run on your pages);
  • cookies and trackers set before the visitor consents;
  • whether an accessible privacy policy is present.

It is a photograph of your website, the one your customers, your partners, and attackers see first.

I recommend starting there for a simple reason. A security analyst is expensive by the hour. Paying one to discover a missing header or a Google tracker that loads before consent wastes your budget. Your developer or your MSP can often make those fixes in a day.

When the report is clean, you have settled the basics. You have not yet tested what happens behind the login page.

What a scan cannot see

In January 2026, an independent researcher found he could read other Meta customers’ support files (conversations, attachments, contact details). He had chained several authorization flaws: the server did not check whether the person requesting a file was allowed to see it. Meta fixed it in April, found no sign of malicious exploitation, and paid him a US$78,000 bounty.

Meta’s site did not have a certificate problem or a missing header. The problem was in the application logic.

An automated tool does not know who you are. It does not know that invoice 1042 belongs to Ms. Tremblay and invoice 1043 belongs to Mr. Gagnon. When it requests the page, the server answers normally. To the tool, everything is fine.

To see the problem, you have to sign in with account A, request a resource that belongs to account B, and observe that the site delivers it. That takes a person who understands what the application is supposed to do, with several test accounts.

This kind of flaw has a name: broken access control. It ranks first in the OWASP Top 10 2025, the reference list of application risks. According to the data compiled for that edition, every application tested had some form of broken access control.

It is not a rare case. It is the most common one.

The same problem, in a simpler form

On September 28, 2026, UpGuard published research on Supabase, a cloud database widely used to build web applications quickly, often with AI-assisted development tools. It found more than 16,000 databases whose tables were readable by anyone. Among the cases cited, a Canadian immigration service exposed 5,000 user files, including 884 plaintext passwords.

The cause is almost always the same: the rules that limit each user to their own data were missing or ineffective. The site showed the right information to the right person. The database answered everyone. Your website can look clean on the surface while your database is wide open.

What an in-depth review covers

At Certi360, application testing is based on the OWASP ASVS (Application Security Verification Standard). Version 5.0 has 345 requirements spread across 17 chapters and three levels, depending on how sensitive the application is. I have already explained this standard in detail here.

In practice, the analyst receives accounts at different privilege levels (user, manager, administrator). Tools are used, but the main work is manual: checking that each expected control actually exists and holds when it is pushed.

What deserves to be tested in depth

Here is what no surface scan can confirm for you. I describe it in a manager’s language, not a developer’s.

Other customers’ data

Can a signed-in customer see another customer’s invoice, file, or document by changing a number? That is exactly the Meta flaw.

Functions reserved for administrators

Can an ordinary user reach an administration page, export the customer list, or change a price if they know the address?

Business logic

Can someone apply a promo code twice, order a negative quantity, skip the payment step, or change the amount sent to the payment processor? These flaws are specific to your application. No generic tool knows your rules.

Password reset

This is often the weakest door. Does the link expire? Can it be reused? Does the site confirm that an email address exists in your customer database?

Two-factor authentication

Is it mandatory where it should be, or can it be bypassed through another path, such as the mobile app?

Sessions

Does a session stay active after logout or after a password change? Does an employee who leaves the company keep an open session on their phone?

The database behind the site

If your application was built with Supabase, Firebase, or a similar tool, are the rules that limit each user to their own data turned on and tested? That is the question 16,000 application owners did not ask.

The API behind the site or the mobile app

The screen shows the customer’s first name. The API sometimes returns the full file, including date of birth and address. The visitor does not see it. An attacker does.

File uploads

If your customers or applicants submit resumes, invoices, or photos, what stops someone from uploading a malicious file or viewing other people’s files?

Forms

Checks made in the browser can be bypassed in a few seconds. The real question is whether the server also verifies what it receives.

Volume limits

Can a legitimate account view a thousand files in an hour without anything blocking or alerting? That is the Communauto scenario: a real account, a script, and files downloaded one after another. An in-depth test checks whether the application limits what an account can extract, whoever is using it.

Logging

If an incident happens, can you reconstruct who viewed what? At Communauto, detecting unusual activity made it possible to cut access during the night. Without usable traces, you cannot assess the risk of injury or document the incident the way Loi 25 requires.

Does your site really need this?

Not always. I would rather say so.

A website with no login, no form that collects personal information, and no payment does not need an ASVS test. A surface scan, regular updates, and basic hygiene are the minimum.

As soon as your site has a client area, an employee portal, a form that collects personal information, online payment, an API, or a mobile app, the question changes. It is no longer only your website that is exposed. It is your customers’ data.

In Quebec, the private-sector privacy law requires reasonable security measures given the sensitivity of the information (section 10). It also requires a privacy impact assessment for any project to develop or redesign a system that processes personal information (section 3.3). To answer that assessment honestly, you need to know whether access controls work, not only whether they exist on paper or in a vendor’s promise.

For an ASVS test of an SMB web application, plan on CA$5,000 to CA$35,000 depending on the depth of the test and the number of functions, roles, and APIs to cover. That is the budget people hesitate to spend before go-live and regret not having spent afterward.

In practice

Here is the order I recommend:

  1. Run your site through loi25.certi360.com and fix what comes up.
  2. List what sits behind a login: client area, portal, API, mobile app, uploads.
  3. If that list is not empty, plan an application test against the ASVS, ideally before production or before a major redesign.
  4. Prepare test accounts for each role and name the person who will sign the test authorization.
  5. Require an independent test report from your vendor, rather than a simple confirmation that “it’s secure.”
  6. Have the fixes retested. A flaw reported as fixed is not a flaw verified as fixed.

The three test levels we offer are described on our Information security testing page.

In short

At Communauto, detection limited the damage. At Meta, an outside researcher found the flaw. In both cases, the answer was not in what a website scan can see. I do not know how many Quebec SMB client portals are in the same situation today, but I know no automatic tool can tell you.

Start with a quick test of your website on loi25.certi360.com. To go further, let’s talk.

References