I manage a SharePoint Foundation 2010 site, hosted by a web hosting company, that is an Internet-facing site. Most of the lists (Calendar, Announcements, etc.) are for public (anonymous) consumption. For some lists I want to show SOME data to the public. For example, I have a list of members (300+) and I want to show certain views (the current officers, about 10 items, just showing name and title) but hide all other views, and most of the fields (email, phone number, etc.)

I know I can hide the Site Actions menu, and the link to All Site Content; and I have already done that. However, a savvy user (or search bot) can reach the _layouts/viewlsts.aspx page and see all the lists, even if they are not shown in the Quick Launch. Thus, they can reach the AllItems.aspx page for my members list, and then see all views for the list. If I could assign a Permission Level for anonymous users, I would; but I can't do that either.

Since 2010 does not allow us to set permissions for views (why that functionality has not been added in 2010 eludes me), what is the PROPER way to secure an Internet-facing 2010 site?

One final note, setting Anonymous Access to "Lists and Libraries" doesn't work either; the default home page (the top-level site is the standard Team site) is no longer accessible under that condition, unless the user knows to type in SitePages/Home.aspx. What user knows to do that? The home page is not visible on the Top Link bar either. So, Anonymous Access has to be set to "Entire Site".

4 Answers 4


Granted that this is a hosted SharePoint 2010 system I believe we can safely assume that modifying internal pages like _layouts/viewlsts.aspx is a no-go.

So, here is another approach taking this into account:

  1. Create a new WebPart page and add the view of your list of choice.
  2. Repeat this for all lists you want to hide from _layouts/viewlsts.aspx.

Open the site with SharePoint Designer and locate the list in question and:

  1. Change the list to "hide from web browser".
  2. Repeat this for all lists you want to hide from _layouts/viewlsts.aspx.
  3. Open the created WebPart page and wrap the listview WebPart into a SharePoint:SPSecurityTrimmedControl as mentioned already.

Save and close SharePoint Designer.

This should make the list invisible from anonymous users and search engines.


First, you can keep anonymous users and even search bots from getting to the hidden view all site content by turning on the viewformpageslockdown feature. This will keep users from being able to find your list in ways that you do not provide. Another thing you can do is to place the view you want the users to see in a web part page, instead of linking them directly to the view in the list. That way they have no way to browse to the list itself, an can only see the view that you have created for them.

  • Forgot to specify that, ViewFormPagesLockDown does NOT work on Foundation, it is only available for SharePoint Server 2010.
    – CigarDoug
    Commented Oct 31, 2011 at 18:42
  • Your second comment is accurate, and is what I am currently doing, but ONLY works for users who are not savvy. Users who know SharePoint, and bots that will detect and crawl any aspx page, will find the All Site Content page and then the members list page on their own.
    – CigarDoug
    Commented Oct 31, 2011 at 18:45

Depending on how strong the requirement is, you could customize the viewlists.aspx page in your _layouts directory. This would be a deep customization, it would take you out of support from Microsoft. So, you'll want to consider this choice carefully. (More on this in the MS article below)

Click Here to review an article from MS on customizating application pages:

From the article:

Modifying the files that are installed by SharePoint is not supported. However, there are some scenarios in which you may have to modify these files to achieve consistent branding or other customizations.

With that said, in the _layouts/ViewLists.aspx page, you could use the SPSecurityTrimmed Control to security trim the table on the page that displays the site's lists. As a file, the page's security would not change, but it would only render the content to users with the permission level defined in the PermissionString attribute.

Look for the table in your viewlists.aspx page where the class attribute is ms-viewlists, then wrap the whole table in a SharePoint:SPSecurityTrimmedControl tag as below:

    <SharePoint:SPSecurityTrimmedControl id="something" runat="server" PermissionsString="EditListItems">   
    <table cellpadding="1" style="border-collapse: collapse;" cellspacing="0" border="0" width="100%" class="ms-viewlsts">
    <!-- All of the out-of-the-box content is here -->

A further word of caution: this solution may break or be completely overwritten when your farm is upgraded and the file is replace or updated during the upgrade.


I think that your design does not really fit the SharePoint security model. If you would want to leverage SharePoint standard functionality you have to find a way to separate the data into two lists: one for anonymous access and for 'private' access.

A work-around for your current scenario is to build a little custom HTTP module and register it in web.config. The module should ensure that anonymous users cannot access the viewlsts.aspx and other pages.

  • Actually I believe a custom HTTP module is quite a little bit overkill as it fires on every request, including any file like CSS, JS, DOC, etc.. Instead a simple ASP.NET WebControl registered as DelegateControl on the "PlaceHolderAssitionalPageHead" with a custom feature would do the same without messing wiyj web.config. But as the TE already indicated s/he is running in a hosted environment which most likely does not permit farm-wide solution deployment.
    – Sig Weber
    Commented Nov 13, 2011 at 8:18
  • Sorry about the typos. Haven't had my daily dose of caffeine yet. Should've read "PlaceHolderAdditionalPageHead" and "without messing with web.config".
    – Sig Weber
    Commented Nov 13, 2011 at 10:34
  • Hmmm, I am not sure about this one. I would hope that you have access to web.config in a hosted environment or at least the possiblity to run SPWebConfigModifications via a feature activation or something else - so registering a HTTP module should not be the problem. Secondly I think a HTTP module is a very good place for any kind of 'filtering' logic based on the URL exactly because it is invoked on all requests with SharePoint (btw. this is not the case for a ASP.NET web site). Images, css ans scripts are anyway cached on the client and only requested rarely... Commented Nov 18, 2011 at 17:44
  • All hosted SharePoint offerings I have evaluated and/or used myself over the past seven years neither allowed web.cobfig access nor deploying SharePoint farm scoped solutions to run SPWebConfigModifications via a feature. However, I'd be happy if you could proof me wrong and provide a name of a commercial hoster which does.
    – Sig Weber
    Commented Nov 19, 2011 at 1:26
  • One of the cheapest providers of SharePoint 2010 foundation I could find (DotNetPark.com) give you full access to web.config and bin folder. So no problem here to get an HTTP module into the pipeline... Commented Nov 20, 2011 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.