Deny All, Then Allow

There are two possible approaches when restricting access to website content:

1. Allow all, then deny if not authorized.

In this approach, the client is handling security. No separate implementation paths are required on the server and returned resource is always the same for authorized or non-authorized users. If authorization fails, a floating popup overlays the content, prompting to login. The content is hidden behind a popup or blurred.

If the user authorizes successfully, the cookie is set and the page is refreshed, removing the overlay. Because the cookie has an expiration date, subscription status is rechecked periodically.

2. Deny all, then allow if authorized. Here security is handled server-side, so two separate paths are required for resource retrieval. If the authorization condition is not met, build the page with a login screen, otherwise display the content. The session key should be validated/replaced on each request.

Which approach is better?

It's a standard security recommendation to deny all, then allow. But why?

Let's review the reason for these real examples that I've randomly plucked from the internet. The examples are accurate at the time of writing (who knows, maybe the security will be tightened up in the future!).

We will run from least effective to most effective.

The New Yorker: Allow then Deny

New Yorker allows five free articles per month and then puts up a paywall request. The view count is stored in the cookies, so clearing up the local storage resets the count.

There is no server-side validation for authorization, and the article content is loaded fully.

We know it's loaded fully because the popup is displayed on the transparent black background and frame scrolling is enabled. You can read the entire article by just viewing the top few visible lines. Inconvenient, but not very pay-wallish.

And if you don't want to be a weird person who reads articles by squinting at the top few lines, reader view works great by removing all unnecessary elements which include, among others, paywall requests.

Paywall efficiency: 1 (an effort was made)

The Atlantic: Allow then Deny, but less scrolling

The Atlantic allows four unique free articles per month and blocks the view with the paywall popup after. When the monthly limit is reached, they smartly disable in frame scrolling and put up a non-transparent call to action popup prompting you to subscribe.

The view counts are also stored in the cookie arrays. That means that merely clearing session and local storage resets the view counter back to 0 (and it is straightforward to figure out which exact cookie it is).

Checking out the source reveals that the article content is present on the page, just not accessible by scrolling and covered by a popup. Of course, ordinary people won't be looking at the source or cookies.

They may, however, just use the reader view which works great.

Paywall efficiency: 2 (kudos for disabling scroll and making opaque popup, still not very secure)

Townhall: Allow then Deny-ish (trying to be clever)

Townhall provides VP content, which is paid-only access. There are no free previews.

At a first glance, unless the user is authorized, the content is truncated, so you can only view the first few paragraphs. Viewing the source confirms truncated content and because of that, reader view won't reveal anything special in addition to what is seen on the page.

There are no cookies to clear because server-side authorization is required.

However, it is still "Allow then Deny" approach but with a twist.

If the user is not authorized, the JavaScript executes on page load and removes the largest portion of the content after the preview marker. Clever! But since the entire page is already fully loaded just before it is truncated, clicking X to stop execution reveals the entire content.

Or, if you want to be all techy and whatnot, open developer console, disable JavaScript on the page, refresh, and hey, no VIP pass required and you now have the "super-secret VIP only access".

Paywall efficiency: 3.5 (may get lucky, moderate tech skills required)

O'Reilly Media: Deny then Allow

O'Reilly Media is a treasure trove of technical books and videos. You don't have to be logged in to browse, and the table of content is fully visible to non-authenticated users. If you hover over, the full chapter link is shown, but clicking the link requires you to log in or register.

What happens if you just type the link in the browser? The server performs authorization validation, and if you are not authorized, it returns an abridged version (i.e., just a few paragraphs with a subscription screen on the bottom). Checking the source and reader view confirms that the page never displays full content.

After logging in, you are redirected to the originating URL. A user-id session cookie is saved in the browser and used for each request to the server. The cookie has an expiration timestamp which forces you to re-authenticate, allowing you to re-validate the subscription.

Paywall efficiency: 5. You cannot get the content without paying for it or hacking into the actual server.

Lessons Learned?

Making something inconvenient to access for the user does not make it secure. You should not try to invent your own security. Client-side security is always less reliable; it's easier not to give someone information at all, then present it and then attempt to hide it.

I don't like saying "Never do X" because, in some cases, doing X is just fine. If someone reads six free articles a month instead of four, what would that do to your business?

In my opinion, Allow then Deny is an afterthought. It usually happens like this - you are sitting there, crafting a pixel-perfect footer when your boss pops up and says "Good news, Jenkins! We are going to sell our content starting next week! Make sure everything is the tip-top shape and working, would you?" What can you realistically do in one week that is production-ready?

The real lesson is to make sure your business sponsors have a good idea of what they are asking for and getting. You may say "Well, we COULD do this in a week, but anybody who knows what browser reader view is would still be able to read the content". And if the risk is acceptable to your business, by all means, document it in excruciating details and move on.

But if you are trying to limit access to secure, private, or sensitive information? Follow best practices. Always.

And if you are purchasing a third-party system to show and sell your content, take it for security spin first. By now, I recognize a framework that seems to be used by most local news outlets and it is too Allow Then Deny model.