Public reporting form

The form is the front door for anyone who wants to report a vulnerability to you: researchers, customers, integrators. It lives at an address dedicated to your organisation and can be embedded in your own site. Every submission creates an inbound signal (INCOMING), with a timestamp — not a case: no legal clock starts until a person promotes the signal to a case.

Your form's address

You find it in Account area › Embedded form, in the shape:

https://cranotify.eu/f/<form code>

The code is random and non-enumerable: your address does not lead to anyone else's. The root of the form domain is not a public page: without a code, visitors are sent to the marketing site.

Embedding it in your site

The same screen supplies a ready snippet:

<iframe src="https://cranotify.eu/f/<code>?embed=1"
        width="100%" height="640"
        class="embed-demo"
        title="Report a vulnerability" loading="lazy"></iframe>

With ?embed=1 only the form card is rendered, without header or surrounding text: it fits into your security or contact page. The form is the only surface of the product that may be framed by another site; everything else refuses to be.

What you can customise

The security.txt file

The screen generates the content of the file specified by RFC 9116, to be published at https://yourdomain/.well-known/security.txt. It carries your form's address, the mail alias, the preferred languages and an expiry date. It is the standard way a researcher finds where to report: publish it — it takes five minutes and stops reports landing in somebody's social media inbox.

What the reporter sees

1. Your name, the introductory text, and the list of products to choose from.
2. A description field (10 to 5000 characters), an optional contact address, and up to three attachments (5 MB each).
3. On submission, a generic received screen: the message arrived. The public surface never confirms whether a product or an organisation exists, and assigns no public case number.

What happens on your side

• An inbound signal is created, visible under INCOMING (/signals): it is not yet a case and starts no legal clock (see Cases: from signal to case).
• A person reviews it and decides: promote it to a case (you set awareness at that moment), attach it to an existing case, or dispose of it as duplicate, informational or dismissed.
• The security mailbox configured in the escalation receives notice of a new signal.
• If you connected Slack, Teams or a webhook, it arrives there too (see Slack, Teams and webhooks).
• The registry records the signal intake (signal_created), with the coordinated-disclosure channel as its reference.

Responding to the reporter

The «received» screen is not an answer: it only says the message arrived. The substantive response is yours, on the coordinated-disclosure timing agreed with the researcher. The address they left is on the signal detail, and is carried into the case when the signal is promoted.

Defences

The form is public and unauthenticated, so it is protected at several levels: per-source rate limits, a honeypot field and a minimum completion time, an optional anti-bot check, entry as an unpromoted signal and untrusted handling of attachments. Details in Quarantine and anti-abuse defences.