SECURITY
Your metadata.
Never your credentials.
Did you find this in your access log?
notafter/0.1 (+https://notafter.dev/security)Someone used our free checker against a metadata URL belonging to your identity provider. The request was a single GET for a document you publish for public consumption. Nothing was authenticated, nothing was written, and no other path was touched.
If you would rather we did not fetch your metadata at all, mail us at the address below and we will refuse that host.
What we read
Two kinds of document, both published by the identity provider itself:
- SAML metadata — the signing certificates, entity ID, endpoints and NameID formats.
- OpenID discovery documents and the key set they point at — issuer, endpoints and key identifiers.
These are the same documents your service providers read to establish trust with you. We read them the same way, and we read nothing else.
What we never ask for
- Administrator consent in your tenant, or in your customers’ tenants
- Passwords, API keys, bearer tokens or OIDC client secrets
- Directory, mailbox or user data of any kind
- An agent, extension or anything installed on your infrastructure
This is a deliberate product constraint, not a stage we intend to grow out of. A monitoring service that holds no credentials cannot leak any, and it means adopting notafter needs no security review of a vendor you have never heard of.
How the fetcher is constrained
The checker takes a URL from an anonymous visitor, which makes it a server-side request forgery surface by construction. It is bounded accordingly:
- Public documents only
- We fetch SAML metadata and OpenID discovery documents. Both are published by the identity provider precisely so that relying parties can read them.
- http and https, ports 80 and 443
- No other scheme and no other port is dialled, ever.
- Public addresses only
- Any hostname resolving into private, loopback, link-local or carrier-grade NAT space is refused before a socket opens — including cloud instance metadata endpoints. The check runs against the address the connection actually uses, and again on every redirect.
- At most two redirects
- Each hop is revalidated from scratch.
- 5 MB and 10 seconds
- Response size is counted from the bytes that arrive, not from the Content-Length header. The deadline covers the whole redirect chain.
- No XML entity expansion
- Entity processing is disabled and any document carrying a DOCTYPE is refused outright.
- One request
- A check is a single GET, made when a person asks for it. We do not crawl, we do not enumerate paths, and we do not retry on a schedule unless someone has explicitly added a connection for monitoring.
What we store
From a free check: nothing.
The document is fetched, parsed in memory and rendered back to whoever asked. It is not written to a database and not retained. Analytics record that a check completed and what kind it was — never the URL, the document, the certificates or the fingerprints.
From the waitlist: your email address.
Used once, to tell you when monitoring opens. Not shared, not sold, and removed on request. The privacy noticecovers the detail.
Reporting a problem
If you have found a way to make the checker reach somewhere it should not, we want to hear about it before anyone else does.
Please give us a reasonable window to fix it before publishing. We will credit you unless you would rather we did not.