Google Workspace public links don't die with one switch

· Security, Google Workspace Administration

Written with Kimi (kimi-for-coding).

I was auditing Google Workspace for a company — the kind of role where you’re the “IT person” (the one who gets everything dumped on them). And there they were, file after file, shared with “anyone with the link.” No login needed. If you know the URL, anyone on Earth can open the contents. HR files, in that state.

The fix looked simple. “Turn off ‘anyone with the link’ for the whole org, and we’re done, right?” The admin said so. I thought so too.

Then I actually did it, and hit three traps in a row. Here’s the story of getting beaten up, one trap at a time.

Trap 1: I went pale at “everything must be consolidated into groups first” — it didn’t have to be

First, get the lay of the land. This company handed free Google accounts to the staff working in the field. From Workspace’s point of view, those free accounts count as “external users.” So I went through every file in the shared drives, and… of roughly 9,700 files, 99.9% were individually shared with those external accounts.

The blood drained from my face. “Wait. Do I have to clean up all of these before killing the public links? All 9,700?”

Pause. Cool my head for a second. The org switch only kills “anyone (= whoever has the link).” Individual shares and group shares survive the switch. They keep working, no matter what. So those 9,700 individual shares work exactly the same, public link or not.

I had mixed two completely separate problems into one and scared myself:

  • Remove public links (= the actual security goal)
  • Consolidate the mountain of individual shares into groups (= plain housekeeping, an entirely different matter)

Don’t mix them. The moment I split them, the work shrank dramatically.

For files meant for the field staff, anything only reachable via public link had to move to group sharing first. Then the person in charge hit me with a sharp question. “This spreadsheet is the data source for a note-taking AI tool. If you remove the public link, will it stop being able to load it?”

I froze for a second. Honestly, I couldn’t answer right away how that AI tool reads the source file.

So I flew a single canary (a poison taster). Removed the public link on just that one file, and re-synced on the AI tool side. …It went through. Loaded just fine.

Here’s the trick. That AI tool ingests sources under the account of whoever registered them, and keeps a snapshot. It doesn’t need a public link. If the registrant can view it, that’s enough. If I had left it public on a “probably necessary” — that would have been the real incident.

Trap 3: I flipped the switch, and the scan count didn’t drop by a single file

Now the main event. In the org’s sharing settings, uncheck “make content public to anyone who has the link.” I left external sharing itself ON (I want group sharing to keep working). Save. Great, done.

Or so I thought — so I re-scanned for public links to double-check. 35. …It didn’t go down. Huh, it didn’t work? Did I fail to save?

No. That wasn’t it. The org switch kills the feature, but the “anyone” permission metadata stuck into each file stays behind. So a scan (API) that counts permissions shows exactly the same number as before. I was one glance away from concluding “it didn’t work” by reading the number alone.

The right way to check wasn’t a permission listing. Log out, and actually open the public link yourself.

I hit the public link with no credentials. What came back wasn’t the file’s contents — it was a redirect to the login screen. Folders, images, everything got kicked to login. Public access was properly dead.

API numbers lie (more precisely, they’re counting something else). Life or death, you check by logging out and seeing with your own eyes.

Bonus: the “stragglers” you can’t remove one by one are exactly what the org switch is for

By the way, while removing public links file by file, some files just wouldn’t die. Ones inheriting permissions from a parent folder. Ones that bounced me because the executing account’s permission wasn’t enough. Ones that said “expansive access” and refused to come off without an org admin’s rights.

These stragglers that individual deletion can’t drop. This is precisely the territory the org switch sweeps away, feature and all. Manual cleanup and org settings aren’t a strict upgrade of one over the other. They just have different roles.

What I learned

“Turn off public links in the org settings” is one checkbox on the surface. But underneath, it was three verifications:

  • What survives (individual and group shares don’t die)
  • What doesn’t actually break (the AI tool doesn’t need a public link)
  • Whether it really worked (not API numbers — log out and hit the real link)

Before you “turn off public links,” know that individual shares survive. To confirm it “worked,” don’t read a permission list — log out and actually access it.

Behind one checkbox, three places to get punched. Everyone, please be careful before you touch your org’s sharing settings.