Agreed. Once we got the SQL-Ledger codebase somewhat stabilized security-wise in LedgerSMB, we started removing it in favor of a secure-by-default framework. Our approach might not work well for other projects and it has its own security pitfalls (which we clearly document, and prevent by default), namely the fact that credential reuse is important and therefore you have to do something like HTTP-BASIC or HTTP-KRB5 auth (and hence for the former SSL really is required).

The way we do it is by not trusting the application. All authorization happens by levels further back, such as permissions granted to run stored procedures or on relations (permissions are granted to relations where there really is a clear, coterminous mapping between relational operations and procedural ones).

We then provide a framework for handling all of this. It means that as-yet-undiscovered flaws in our application are not as exploitable as they might be because the app is not trusted by the database.

The scaffold Rails generates isn't insecure by default, it just doesn't automatically generate example cases that require input validation. Perhaps it should be laden with comments about how to validate input when your code does eventually require it.

You can't blame the framework for people failing to validate input. The framework can provide you abstractions for helping you validate input, but at the end of the day, if you're being lazy or sloppy about what you do with data from the outside, that's your fault, not the framework's.