So for example rails handles basic things like SQL injection, XSS in standard forms fine, then you can use devise or similar for authentication and get a reasonable level of security. What you're left with are areas like authorisation which tends to be app. specific so still requires work, but you probably have less to focus on.
Also watch out for what I'd call "dangerous" functionality, things like file uploads or user generated content where you want users to enter HTML tags but still avoid XSS. Things like that need specific consideration to avoid common security issues.
Of course if you're doing something that will attract real bad guys (anything to do with payments, anything to do with bitcoin, anything to do with Intellectual property management etc) then I'd strongly recommend getting an app security person on staff as soon as you can 'cause you will get attacked probably sooner rather than later...
Although the downsides of this are the possible vulnerabilities in the framework itself (as well as the potential learning curve and lock-in) there are likely to be more people using, and finding, those vulnerabilities than would be in your quick-and-dirty handrolled quasiframework. Even if the latter is more fun.
And if you're on shared hosting... umm... you should probably reconsider that. If that's not likely to happen soon, then database-driven sessions, regular backups and SSL are a must.
OWASP could be doing a lot more but their PoC and descriptions are pretty good.
Your next step is to think about how you will be preventing them. An example, If you are writing a PHP site without a framework, how will you generate, validate, and store CSRF tokens? How will you filter output? How will you architect your web-app to prevent SQLi?
Security consulting is ridiculously expensive and I've seen companies pay a lot to get told very little. If you want to run security concerns by me, I am free to contact.