Bora

Worth saying plainly since it is the elephant in the thread: if the data behind the paid API is valuable enough to be worth protecting properly, put it behind a login.

Authentication is the thing that actually answers "who is calling". Everything else in this thread is damage limitation for the case where you have decided the page must be public. That is often the right decision for reach and conversion reasons — just make it knowingly, rather than trying to get authentication's guarantees without authentication.

The organisational argument that usually moves teams faster than the technical one: a shared spreadsheet makes shared accounts the path of least resistance, and shared accounts are the underlying problem.

When the credential store is a file everybody opens, the natural design is one account that everyone uses. That destroys attribution — you cannot tell who did anything — and it makes offboarding a rotation exercise instead of a deletion.

A password manager makes individual accounts and per-person access easy enough that teams drift toward them. The tool changes the default, and the default is what you actually end up with a year later.

So the answer to "what does the spreadsheet fail to do" includes things that are not about the file at all.

For the forward-looking part: offering a customer testing policy proactively is worth more than it costs.

Enterprise customers increasingly want to test their suppliers, and a supplier who says "here is the process, here is the window, here is the staging environment" looks far more mature than one who has never considered it. It also means the next customer who wants this asks you first, which is the actual outcome you want.

Many platforms publish exactly such a policy. It turns an awkward request into a form.

Worth adding the protective measure on the carrier side, since that is where the realistic attack lives: most operators will let you add a port-out PIN or a transfer lock to your account.

It is a short phone call, it costs nothing, and it directly addresses the failure mode that causes essentially all real-world cases. If you are going to keep a phone number as a factor anywhere — and most people have to somewhere — that call is the highest-value ten minutes available.

Speaking as someone who has written one of these announcements: the stated reason is usually a simplification, and the real reason is almost always manageability rather than vulnerabilities.

The common drivers:

• Policy control. Enterprise environments push settings centrally — allowed extensions, certificate handling, blocked sites, update enforcement. Browsers differ a lot in how well they integrate with a given management stack, and one that cannot be centrally configured is a browser IT cannot make guarantees about.
• Traffic inspection. Regulated industries are often required to inspect outbound traffic. Browsers that maintain their own certificate store, or resolve names over their own encrypted channel by default, bypass the inspection infrastructure. That is a feature for a user and a compliance failure for the organisation.
• Supportability. Every additional browser is another platform to test internal applications against and another set of support calls.
• Attack surface reduction. Fewer installed applications is genuinely a security position, independent of any one product's record.

Notice that none of those mean the browser is insecure. "We cannot manage it" is a real security concern and it is not the same statement.

The supporting controls that come with it, since resetting alone is not the whole story:

• Users run without administrative rights, so most installation attempts fail in the first place.
• Software restriction policies allow only approved applications to execute.
• Network isolation puts public machines on their own segment with no route to anything internal — this is the control that protects the organisation rather than the user.
• Application allowlisting on the proxy limits where the browser can go.
• Physical measures — locked cases, disabled ports on some deployments.

Worth noting how much of this protects the operator rather than the person sitting down. The library's concern is that the machine cannot be used as a foothold into their network. Your safety as a user is a secondary benefit of a design aimed at something else.