The only account is a pipeline: access control when nobody logs in

A showcase or brochure platform with no customer accounts looks like it has no access control problem. No login form, no password reset, no role matrix. Then look at what writes the pages. A01:2025 – Broken Access Control maintains its position at #1 as the most serious application security risk, and the contributed data indicates that, on average, 3.73% of applications tested had one or more of the 40 CWEs in that category. A pipeline is an actor.

Nobody logs in, but something writes

On the multilingual platform we built for a biomass boiler manufacturer, SEO articles published every day: 8, across four country domains indexed separately and seven languages served, with manual intervention required: 0. On a server-rendered personal platform, articles publish autonomously daily with model fallback levels: 3 and weekly content operations time of roughly zero hours. In both cases the credential that can create published content belongs to software, not to a person.

That reframes the question. It is no longer whether the visitor is authenticated, but what the publishing identity can reach once it is. Can it delete as well as insert? Change configuration? Write to a domain this run was not scoped to? With one codebase serving four country domains, a write path authorised at the codebase level rather than the domain level is a cross-market surface by construction.

A01 is forty weaknesses, not one check

A category spanning 40 Common Weakness Enumerations is not discharged by a single gate at the edge. Authorise at the point where data is read or written, not only where the request arrives. Deny by default, so a new endpoint added by next month's feature is closed until someone opens it. Scope the publishing identity to the narrowest set of operations that produces an article, and nothing adjacent.

The 3.73% figure can read as reassuring, since it is an average across applications tested rather than a prediction about yours. Note what it sits beside: the category is still ranked the most serious application security risk. Incidence and severity are separate axes, and a cheap authorisation boundary on a write path is worth adding well before the statistics feel personally threatening.

Misconfiguration moved up to #2

A02:2025 – Security Misconfiguration moved up from #5 in 2021 to #2 in 2025. For a platform with modest bespoke logic, configuration is most of the attack surface: headers, defaults, exposed endpoints, environment separation. The showcase platform we built for an independent Belgian consulting firm shipped hardened security headers and clean search signals from day one, with technical SEO issues at launch: 0. Configuration done at launch is configuration you are not retrofitting under pressure.

A Content Security Policy should be delivered in the Content-Security-Policy response header, and it should be set on all responses to all requests, not just the main document. That includes whatever endpoint the publisher posts to, not only the HTML a visitor sees. One codebase across four domains means one header configuration to verify per deployment target, which is a checklist rather than a research project.

Generated text is still untrusted input

Setting a CSP is not an alternative to sanitising input. On a platform whose article bodies are written by a model, the untrusted input is your own generated output, and three fallback levels mean three possible producers of the same field. Sanitise at the write boundary where the row is created. Then use nonce- or hash-based fetch directives, a strict CSP, so that anything which does slip through has a smaller blast radius in the browser.

Logging the machine's actions is not alerting

Great logging with no alerting is of minimal value in identifying security incidents. That is sharper when weekly operations time is near zero and manual intervention is 0: nobody is reading the log. Define alert conditions on the write path itself. A publish outside the expected window, a write to a domain the run was not scoped to, or a credential used from an unexpected code path are all answerable questions if you ask them automatically.

Write down every actor that can change what the site serves. On an unsupervised platform that list often has one entry, and it is not a person. Give it the narrowest scope that still produces the artefact, check authorisation where the data is touched, set the headers on every response at launch rather than later, and attach alerts to the write path. None of that requires a login screen to exist.

Sources

OWASP — Top 10:2025 Introduction — https://top10.owasp.org/2025/0x00_2025-Introduction/

MDN Web Docs — Content Security Policy (CSP) — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

Neurolinks case study — Four markets, one codebase — https://neurolinks.be/work/tatano-energy

Neurolinks case study — A personal brand that publishes itself — https://neurolinks.be/work/matthieu-pesesse-media

Neurolinks case study — A consulting firm, dressed for trust — https://neurolinks.be/work/abbys-consult