{"slug":"public-private-data-boundaries","title":"Public readiness is not permission to expose customer data","description":"Design a machine-readable public surface without leaking operational records, credentials, or confidential identities.","sources":[{"name":"OWASP: server-side request forgery","url":"https://community.owasp.org/attacks/Server_Side_Request_Forgery"},{"name":"IETF: Robots Exclusion Protocol, RFC 9309","url":"https://www.rfc-editor.org/rfc/rfc9309.html"}],"sections":[["Inventory the data before the endpoints","A public audit needs publishable identity, declared policies, documented capabilities, and reproducible technical evidence. It does not need order histories, raw email addresses, session tokens, customer preferences, support messages, or payment records. Start by writing down which fields belong in each evidence lane. A publicly reachable website is not automatically approved as an identifiable case study."],["Use three lanes","The public lane contains specifically approved observations suitable for publication. The connected lane contains authorized operational evidence with access controls and retention rules. The private review lane contains material needed to investigate a disputed observation. Moving a record between lanes requires explicit release review rather than a convenient serializer."],["Treat returned documents as untrusted","A fetched page can contain instructions aimed at the observer. Its text is evidence to inspect, not authority to send credentials elsewhere or invoke another endpoint. The same principle applies to machine manifests and source documents: a declaration may describe a service, but it cannot grant itself access to the auditor’s environment."],["Minimize evidence exports","A public record can include an approved subject reference, observation period, response class, methodology version, evidence state, and sanitized explanation. Do not publish raw headers by default. Cookies, authorization values, source-domain hashes, distinctive asset paths, private query strings, and small-cohort metrics can reveal a confidential participant even when its name has been removed."],["Verify the boundary","Test that public endpoints reject unsupported methods, do not accept secrets as query parameters, and do not return connected account data. Test that noindex or robots rules are not being mistaken for authentication. A public report should explain its evidence limitations without exposing private source records or encouraging a reviewer to cross an access boundary."]],"next":"credential-minimized-observation","published":"2026-09-26","updated":"2026-09-26","status":"published","author":"AIWebSignals Research","url":"https://aiwebsignals.com/research/regulated-commerce/public-private-data-boundaries","example":{"type":"synthetic","heading":"An identifier can still identify","text":"A synthetic draft removes a company name but retains a distinctive asset path and an exact private incident timestamp. The record still fails publication review. Hashing the domain would not make the single-site story independent evidence or remove every route to identification.","exercise":"Review HTML, metadata, exports, citations and filenames together. Use invented fixtures or explicitly released evidence, not a renamed private record. Keep the authorized working record outside public assets."},"methodology":"https://aiwebsignals.com/research/regulated-commerce/methodology"}