Security can't be added-on, it must be baked-in.

Let's take a look at the data access protocol for tomorrows applications: OData. It was originally designed to allow easy access to open data sources without any sensitive information. But with the advent of the single page app it becomes more and more likely that the only thing needed from the server is the data. With native support for OData sources for every form, grid, or other representation of data in nearly every framework, OData will be used to access private and company data as well.

OData has no security baked-in. None. Security can be added at the http-level. By now, we all know pretty well how secure this will be. OData will most likely use a single account that must have enough rights to service all requests from all users. Depending on the actual implementation of your OData provider, someone might even be able to configure some security options for this provider. But will you (the DBA) be asked to set up or even verify this configuration?

I find it very strange that a brand new data access protocol has been designed without any security in mind. With role based security, it is still very easy within a development environment to create a single group 'Everyone' with 'Full Access' rights. But that setup usually triggers some serious security-related considerations before anything goes in production. With no roles and no rights, nobody will notice how easy it becomes to grab some sensitive data using other tools then the intended app. And your OData provider won't notice the difference.