15 years and counting.. I hope this important feature get some attention soon..

C'mon Atlassian!? 

If any given Company has a policy, stating that access to any Space is only gained through externally authorized groups, and the same Company then creates lots Confluence Spaces and assign  users as SpaceAdmin on each their own group space, to handle their own areas. 

Then HOW does this huge expensive enterprise grade collaboration tool ensure that no SpaceAdmin simply shortcuts the Company policy to only use externally authorized Groups in stead of just individually assign access to certain users!!?

Kindly fix this ASAP

We have the same problem please fix this

I concur.  Our use case is similar.  We would like to publish one (1) space with anonymous, and restrict space admin from opening up any other space.  Right now, this would require a 2nd instance which is somewhat ridiculous just to publish a handful of anonymous pages.

Thumbs up on this very important missing feature. Please, please, please do this one. However, it has been open since 2007 .

This one still gathering intertest ? Space admins should not be allowed to give anonymous access to a space but we should still be able to enable this via a confluence administrator. 

Any workaround Atlassian can publish for this? 

We had the same problem here at the University of Helsinki and have now a daily script checking and removing unnecessary permissions for anonymous users (other than 'view' and 'comments -add'). If you are interested in it I can ask further details from our sys admin.

However, there should be more options on the global admin's panel.

I need as the central Admin the ability to exclude the "Anonymous Access" options for Space Admins to enable from certain spaces.
It would be a catastrophy if a Space Admin by accident opened certain content to the public for viewing - even worse for editing.

This is exactly what we need as well.

Writing a script that checks permission and creates an alert if rules are violated sounds like an afterthought solution. Security should never be an afterthought.

The three main problems with script workaround are:

• constant maintenance of the wikis is needed - when an alert is issued a site admin has to log in and fix the issue (this could be automated within the script though I guess)
• there is a window of opportunity for anonymous users to post things from the moment the write access has been granted, until the violation is found and fixed.
• bad user experience - "I turned this on, it was on for 5 hours, and now it's off! This system is weird!"