Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

The pitfalls of transparent security

time to read 2 min | 299 words

A long time ago, I needed to implement a security subsystem for an application. I figured that it was best to make the entire security subsystem transparent to the developer, under the assumption that if the infrastructure would take care of security, it would make a lot more sense than relying on the developer to remember to add the security calls.

It took me a long while to realize how wrong that decision was. Security is certainly important, but security doesn’t apply to the system itself. In other words, while a specific user may not be allowed to read/write to the audit log, actions that the user made should be written to that log. That is probably the simplest case, but that are a lot of similar ones.

Ever since then, I favored using an explicit approach:

var books = session.CreateQuery("from Books")

This also help you implement more interesting features, such as “on behalf of”. And yes, it does put the onus of security on the developer, but considering the alternative, that is a plus.


Stefan Wenig

Sure, that' easier to handle. And I'm sure for some systems, that's the way to go. But make one critical mistake in a multi-tenant system hosting mutual competitors, and you're done.

Transparent security works, you just need to be able to opt out. Sometimes you forget to opt out, this will result in an exception and will hopefully be caught during testing. If not, an unhandled security exception in production is still better than information disclosure.

Another potential advantage: You might want to control who's able to opt out.

Ryan Roberts

Transparently adding a default deny at least might be a good idea


I see what you're saying, and it can sometimes be misleading that if the developer queries for books it only returns a subset of the books. This method is most obvious to the programmer. However, I usually use transparent security with the ability to opt out for the reasons Stefan stated.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats