Personal data in URLs, the WordPress API check, and what a bots-only feed keeps
Salience now masks email addresses in stored URLs, warns when your URLs carry them, checks whether a WordPress site's public REST API lists other people's details, and keeps list reads of that API even on a bots-only feed so a harvest is visible.
A customer found that a quote form on a WordPress site had been saving every request as an entry titled with the person's email address, and that the site's public REST API listed all of them to anyone who asked. Salience spotted it because bots were requesting pages with email addresses in the URL. Three things now make that kind of problem visible by design.
Email addresses in URLs are masked and flagged. When a request arrives, any email address in the path or query string is stored with the person removed and the domain kept: /calculator/jane.smith@example.co.uk becomes /calculator/***@example.co.uk. The daily URL scan behind the Potential credential in URL alert now recognises addresses too, including ones written as slugs such as …gmail-com, and fires a warning that names the routes carrying them, so you can see what puts the address there and whether a public API lists the records behind it. It is personal data, not a credential, so the alert never asks you to rotate anything.
A new Site Check for the WordPress REST API. On WordPress sites the nightly checker lists the content types the public API publishes, reads one page of each and counts email addresses and phone-like numbers in it, checks whether the user list and the Contact Form 7 form list are public, and whether a block on /wp-json/ is bypassed by the ?rest_route= form. A content type that lists other people's email addresses fails the check; a public user or form list warns. Only counts are recorded, never an address, name or number. Sites that are not WordPress show the check as not applicable.
Bots-only feeds keep list reads of the content API. A feed that drops human traffic would also drop a script paging through such a list with a browser user agent. Requests that read a WordPress content collection as a list (with paging or search parameters, the user list, or the types index) are now kept whatever class they fall in, so a harvest is visible in Log Explorer and in the alerts. Ordinary browser calls to the API, such as single entries and contact-form refills, follow the normal rules and are not kept. See Bots-only and no-visitor-IP modes for the full description.