This entry is about Web Content Management (WCM) content security (potentially delivered through a Portal) and does not refer to Digital Rights Management (DRM), although I can see this discussion being extended to discuss DRM as well.

When you talk about securing content in WCM world, it could fall under two main categories, content security and content personalization. It could be surprising to see personalization being talked under the security, but some people still blur the difference between two. Here is my definition to differentiate the two; security, when you should not have access to content if it is not meant for your consumption, personalization, when you don’t see the content on your landing pages, but you can access it through some other means.

Any WCM/Portal application designed to provide this feature has to deal with performance of application, as each user is accessing the pages with different combination of security (groups , roles or profile attributes) resulting in different queries to generate the page Vs. each user accessing the same page generated through one query. If the combination of security attributes is small, overall number of queries for all pages would remain in vicinity of non-secured content pages. But, when you talk about thousands (or millions) of end-users hitting the site resulting in millions of page-views, you would have to think about how much hardware you are ready to use for your site that deliver content security and/or personalization. More combinations you use, chances are high you would end-up using more hardware.

Most WCM/Portal solutions have some kind of caching mechanism to reduce the impact on back-end, but they work efficiently when overall cache-hit is high (cache-hit: same page is accessed by multiple users, so only first user hit would create an impact on back-end, rest access would result in serving the content from the cache). In case of content security and/or personalization, these cache hits are reduced, creating an impact on your back-end systems.

In the end, it boils to down to balancing the two, how much functionality you would provide to end user for content security/personalization Vs. how much you would like to spend for delivering that content through your infrastructure. It is not an easy decision, as we move towards more personalized web, every consumer of your site is expecting this feature, at the same time, the relentless cycle of extracting more out of less puts high pressure on delivering this functionality with limited infrastructure.

If you are in a similar position, you could try to limit the scope of personalization/security to certain pages (you would have to analyze overall use-cases to come up with recommendations) or use an intelligent caching solution (either part of WCM/Portal, or built on top of it). This functionality will make more impact on your infrastructure than non-personalized content, although you can limit the impact through judicious business requirements and/or technical design.

When I first learned about IT security in Internet world, I was told to assume “that some hacker is already in DMZ” before I architect any security framework. It helped me tremendously, whenever I was involved in web-sites security projects or related discussions. I was also aware of direct hacks from the browser, if your application is not written with security in mind. I did not realize how fast this field of “browser hacks” have grown.

While reading a blog entry from John Conroy of CMSWire (How They Hack Your Website: Overview of Common Techniques), it was quite tempting to try some of the hacking options and see if your preferred sites breaks (I tried and could not break it, I am happy about it!). There were good points in the comments by Jason and others to round up the blog with overall perspective.

What jumped out to me from the blog was that how vulnerable web-sites have become that a simple slip can cause a much bigger problem (Harvard Site Hacked, Alleged Content Hits BitTorrent). Of course, with packaged application (as most ECM products are) it is difficult to achieve complete control of code and how it executes different components. So, one of the due diligence you own is asking the Vendors about their application’s design from security perspective that thwarts “browser hacks”. It could also occur when you lack a trained team, who should not only understand the basics of web-sites management, but also design application to be secured at all levels (not just protocol, code and configuration as well).

In this world of highly interactive web applications, it is very easy to put lot of logic in browser to make interactions easy and closer to end-user, but this can open up new pathways to hack into your application, if you do not take appropriate steps to block it. Now, if I am participating in any security discussions, rather then mentioning my old advice “someone in the DMZ”, I say “someone has crossed DMZ and is trying to manipulate your application”.