[mantrax3]

If it's "not a hard problem" - and I agree it isn't, and it's solved by Clojure's SQL libraries, why should the web framework deal with it in any way?

And moving the problem actually helps, when the original place was the wrong place to solve the problem.

Security is one problem when you write queries all over the place. The other two problems are data integrity, and maintenance.

In a service layer you have exactly three concerns:

1) Validate abstract input (and permissions of the caller).

2) Perform the transaction.

3) Return abstract output (and/or errors).

No routers, no controllers, no views, no templates, no CSRF, no XSS, no HTML escaping, no GET, no POST, no nothing.

Just input, transaction, output. Pure data. Pure business logic.

And suddenly things that seemed hard to get right, or things you had to repeat all over the place in your code, get done simply, and just once. And all your web code calls the service layer.

All your iOS and Android app code - also calls the same service layer.

And they're both secure because you need to get the service secure just once - then all interfaces (web, mobile, desktop, API) use the same service.

And when you don't isolate the service, you'll be running SQL all over the place, and use every framework's souped up solutions to avoid SQLi.

Which one do you feel is better?

[lukeschlather]

I've seen SQLi blindly passed from frontend code to a backend service API and then executed. The indirection did help mask the issue so there was no suggestion the attack succeeded or way that it could actually be exploited, but it's perfectly possible to what you describe without actually solving the sanitization problem.

SOA is great for scalability, but not really that much of a boon for security (especially since you now have a problem of authentication between your frontend service and your backend service which is often ignored since it's behind the firewall and nobody is going to be snooping.) (Other than the NSA, GHCQ, and China.)

[mantrax3]

You can always shoot yourself in the foot even with a service layer.

But in a service layer you need to get it right once. And therefore if you don't, you have to fix it just once.

And coupling your business logic with your frontend layer suggests spaghetti code and violates DRY, because you typically have many frontends, but one app state.

Security is about focus. If the service coders can focus on the service being secure & fast, frontend guys can focus on the frontend being usable.

Otherwise you're asking everyone to think about everything, and human attention span, memory and skill sets are limited, and this does affect security.