Best advice I could provide if the devs aren't too knowledgeable on application security, is use a framework where possible, know where it's likely to fail you and focus there and then make sure you stay on top of patching all your framework components to catch vulns in that layer
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...
This is doubly true for PHP. Upgrading an (already likely secure) database class in a framework that uses PDO is a lot easier than changing a thousand calls to mysql_query after the fact. You don't have to worry about wrapping every echoed variable in htmlspecialchars() when you're already using twig. PHP developers keep running afoul of what are already mostly solved problems. Imposing a bit of structure and modularity now will make responses to issues easier 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.
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...