Fictional example

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, worded exactly as the owner would receive it, applied to an invented site built on a hosted builder. A real notice carries the real host, the real date and the technical record.

Security observation notice: Clinique Lavigne (a fictional example)

To: Clinique Lavigne, owner of clinique-lavigne-exemple.ca
From: Marco Presta, Presta Software Inc.
Date: 2026-11-01
Subject: A read-only check of clinique-lavigne-exemple.ca on 2026-11-01: 2 medium, 3 low, 2 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 ran a read-only check of your public website on 2026-11-01. 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.
Your pages can be shown inside someone else’s web page [framing-unrestricted, medium, 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: OWASP clickjacking guidance.

Lower-priority items

Your contact details are printed openly on your page [contact-data-printed, low, observed] Your page shows your contact details in a form that automated programs can copy: one telephone number and one click-to-write e-mail link (the observer never stores the full value). Programs that crawl 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.
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 e-mail 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

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: RFC 8446.

What this means for you, in one breath

Nothing here is urgent. Two of the seven items are Wix’s, three are yours and cheap, two are for your information. The one thing to do this month: the contact details, if you receive spam calls. Then the security.txt line. The second look, after your fixes, says what changed.

How this was observed

In plain words: 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 notice, 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 compliance determination, and your own circumstances decide what matters. This notice is yours; we keep one copy for twelve months and share it with nobody.

Back to Vitrine Ask for your free look