Setting up anonymous access on a SharePoint site can be more complex then simply turning it on at the web application and site collection levels, especially when custom code is involved. In particular, CSOM code will generally not work out-of-the-box for anonymous users. This is by-design; the default permissions mask for the Anonymous user prevents this.
If you turn on anonymous access for a site, and anonymous users are prompted for credentials, you may be running into this issue. ULS logs will show an UnauthorizedAccessException for the CSOM category, most likely when hitting client.svc/ProcessQuery. Filtering the category to only CSOM entries will pinpoint the issue:
The Anonymous permissions mask
By default, the Anonymous user does not have the UseRemoteAPIs permission. This means that client-side code being run by an anonymous user will be unable to call CSOM endpoints, even if Require Use Remote Interfaces permission has been disabled at the web application level and/or site collection level:
As Rodney Viana demonstrates in his blog post here (for a different issue), the Anonymous permission mask can be updated to include UseRemoteAPIs using SharePoint Management Shell as follows:
Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
$webUrl = 'http://muurl' # please replace this URL with your site collection
$web = Get-SPWeb $webUrl
Write-Host "Your web '$($web.Url)' is all set. No change needed";
Write-Host "Effective rights for anonymous: $($web.AnonymousPermMask64)";
Write-Host "Your web '$($web.Url)' does not include the appropriate rights to anonymous"
Write-Host "Current Effective rights for anonymous: $($web.AnonymousPermMask64)";
Write-Host "Adding the appropriate permission";
$web.AnonymousPermMask64 = $web.AnonymousPermMask64.ToString() + ", UseRemoteAPIs";
Write-Host "New effective rights for anonymous: $($web.AnonymousPermMask64)";
Write-Error "Error: Fix could not be applied"
This will allow code to access CSOM endpoints while running as the Anonymous user.
Since the mask is set at the site (SPWeb) level, if you have more than one site, you will have to run this for all sites that need anonymous access to CSOM.
This will open up anonymous access to all CSOM endpoints. While this should not give the Anonymous user access to any data they do not have permission to see, it is worth weighing this as a security consideration.
Even if the above change to the permission mask is made, this does not guarantee access to all CSOM libraries. For example, the Managed Metadata service’s Taxonomy code is hard-coded to require authentication, so calls to it will not work for the anonymous user (specifically, any attempted call to SP.Taxonomy.TaxonomySession.getTaxonomySession will fail with Access Denied). More about this, including possible workarounds, in an upcoming blog post.