Odd issue with security trimming and global navigation

Just figured this one out.

So, right now, we use the SharePoint-managed nodemap in our layout, which is managed via /_layouts/AreaNavigationSettings.aspx and does automatic security trimming.

Recently, I'd noticed peculiar behavior in a couple of places. We would give a deep link to some resource to an external party, and when verifying the security on the new accounts we'd created for those individuals, most of the nodes in the tree would disappear...but not everything. The ones that remained were still not accessible to the user - clicking one would give Access Denied, but still, security trimming should remove these anyway, right?

The tricky bit is partially my fault.

Whenever I create a hyperlink target in SharePoint, I always strive to remove any unnecessary cruft from URLs. I strip off the hostname and the URI specifier, and if the target is a library or list, I remove the view name and just allow SharePoint to fall down to the default view, unless the target is supposed to be a particular list. So, when I have a link target of http://my.server.com/division/office/Lists/Contacts/AllContacts.aspx, I will usually replace that with /division/office/Lists/Contacts. Similarly, in a navigational node (where all the targets are generally subsites), I'd replace http://my.server.com/division/office with /division/office.

Usually.

Sometimes, I would inadvertently use /division/office/. That trailing slash would cause the security trimming to fail, but of course, the security is re-checked on pageload (thankfully!), so while I was violating security by accidentally exposing resources, I wasn't actually granting access to those resources. And in my current job, that's not a big big deal, but we're about to grant site access to a few companies who collaborate with us in some markets and compete in others...and one of the visible links was the name of a moderately high-profile project!

Hijinks with security trimming links

My company has two main web applications, one that is our main collaboration space, and one that is just a playground for HR, more or less. We don't use Publishing on our main site, but HR makes heavy use of publishing on their web application, so that they can circulate and approve draft announcements and the like.

I was charged with making several "benefits portals" for the different territories our employees work within. We already had one for the US, so cloning this out to the other territories was no problem at all. I got a list from HR of what employees were full-time and in which territories, so I set up matching AD groups and SharePoint groups, and the security was all taken care of.

One wrinkle - a new hire browsing the HR site found the benefits portals (which apparently were not ready to be launched yet), and was able to see more than one. I duped her account and sure enough, there it is plain as day, but when I click on the link, I get denied access. That's good, but it's still weird that the link even shows up.

It turns out that the reason why the link is present is because the target had never been published, so there was never a target URL to check for security access. Thus, the security trimming check fails, and so SharePoint treats the link like an external URL and displays it. I assume this also applies to documents with no checked-in version.

So, be aware - if security is the name of the game and even revealing the existence of a document is of issue, then make sure you don't run afoul of this little issue.