Security observation report: Clinique Lavigne (a fictional example)

Mis à jour / Updated: 2026-11-07 10:57 HNE / EST (2026-11-07T15:57Z)

This is an illustration for prospective clients. Clinique Lavigne and clinique-lavigne-exemple.ca do not exist; every item below is a real rule of the instrument, with the severity and reference its rule table gives on 2026-11-07, applied to an invented site built on a hosted builder. A real report carries the real host, the real date and the technical record. English first, French below.

To: Clinique Lavigne, owner of clinique-lavigne-exemple.ca
From: Marco Presta, Presta Software Inc.
Date: 2026-11-01
Subject: A check of clinique-lavigne-exemple.ca on 2026-11-01: 1 medium, 3 low, 3 for information
Handling: For you, the owner of the site, with your agreement. Not published and not shared with anyone else.

Why you are receiving this

With your agreement, I checked your public website on 2026-11-01 without changing anything. My tool opened your page the way a visitor’s browser does, read a few standard files, and did not log in, fill in any form or try to break anything. Your site is built on Wix, so some items below are Wix’s to change, not yours; each item says which.

What matters most, in order

A cookie set by your site is missing the ‘Secure’ mark [cookie-no-secure, medium, observed]. Your site stores a small file in a visitor’s browser (a “cookie”) named XSRF-TOKEN. It lacks the “Secure” mark, a flag that tells the browser to send that cookie only over an encrypted connection. In the usual case there is nothing for you to change: on Wix this cookie is normally Wix’s own, and only they can add the mark. If you want, ask their support whether they plan to. Reference: RFC 6265 section 4.1.2.5.

Lower-priority items

Your pages can be shown inside someone else’s web page [framing-unrestricted, low, observed]. No instruction tells browsers to refuse your pages inside a frame on another site, which is how a copycat page can show your real booking page under its own name. On Wix this header is set by the platform; it is theirs to add. If you ever move to your own server, the one-line header X-Frame-Options or a frame-ancestors rule closes it. Reference: RFC 7034 (X-Frame-Options); W3C CSP Level 3 frame-ancestors.
Outside files load on your page without a fingerprint check [thirdparty-script-no-sri, low, observed]. Three small programs on your page are loaded from outside services (a booking widget, an analytics tag, a font service) without a fingerprint check, so if one of those services changed its file, your page would change with it and nothing on your side would notice. On a hosted builder these files normally belong to Wix and its partners, so there is nothing for you to pin. If you add your own widgets, prefer ones that publish a fingerprint. Reference: W3C Subresource Integrity.
No security.txt contact file on your site [securitytxt-missing, low, observed]. Someone who notices a problem with your site has no published way to tell you. A one-line text file at /.well-known/security.txt with an email address fixes it; on Wix, ask your designer whether the builder can serve it, and if not, the contact page does the job. Reference: RFC 9116.

For information

Your contact details are printed openly on your page [contact-data-printed, info, observed]. Your page shows your contact details in a form that automated programs can copy: one telephone number and one click-to-write email link (the observer keeps only masked samples, never the full value). Programs that scan the web collect anything shown this way, and it can end up on sales-call and spam lists. This is your own content, so it is in your hands: use a contact form, or a button that shows the number when tapped, instead of the printed number. If you prefer to keep them printed, that is a legitimate choice. Reference: privacy and anti-spam practice.
A chat window is referenced in your page’s code [chatbot-present, info, observed]. Your page loads a chat widget from an outside service. Nothing to fix; worth knowing who runs it and what visitors type into it, since that text goes to that service, not to you.
Encrypted connections use TLS 1.2 [tls13-not-supported, info, observed]. The entry handshake negotiated TLS 1.2 and a handshake pinned to TLS 1.3 was refused. TLS 1.2 is still acceptable; this is for information. Enable TLS 1.3 at the edge when your platform offers it. Reference: good practice.

What this means for you, in one breath

Nothing here is urgent. Three of the seven items are Wix’s (the cookie, the framing, the outside files), two are yours and cheap (the contact details, the security.txt line), and two are for your information only. The one thing to do this month: the contact details, if you receive spam calls. Then the security.txt line. The second review, after your fixes, says what changed.

How this was observed

In plain language: the observer opened your page the way a visitor’s browser does, looked at a few standard files, and did not log in, fill in any form or try to break anything. Per host, only: the entry URL with its redirects, the plain-http form of it, two encrypted handshakes, four standard files, and one optional source-map check; at most nine contacts in all. The full protocol is in the how-to that comes with this report, so your technician can reproduce every line.

Context

The reference beside each item is the standard it cites; the severity is the observer’s fixed rating per rule, not an assessment of your risk. Nothing here is a legal determination, and your own circumstances decide what matters. This report is yours; we keep one copy for twelve months and share it with nobody.