Security-by-design based on an existing framework or a custom design?

Question

Personally I do most of the development in PHP (the programming language doesn't really matter for this question). Popular PHP frameworks along developers are for example:

1. CodeIgniter
2. Laravel
3. Symfony

From this three frameworks, I know most about CodeIgniter and in general I think they supply developers with a good input library and pay extra attention to security. Also they have a security program in order for researchers to report vulnerabilities in the framework in order to fix those. Disclaimer: I'm also contributing to the CodeIgniter framework and their security program.

My general question is: is it better to rely on an existing framework for developing an application in order to extend a basic security-by-design structure. Or is it safer to start from scratch and develop everything yourself?

In other words: With security-by-design in mind, is it safer to start developing an application based on an existing application framework or to start from scratch with a custom build design?

Let alone that developers of course need to use the framework functions properly in order to benefit of them. The same applies on custom build functions/features.

Answer 1

If you were to start a framework from scratch, you would have to catalog and address a wide range of possible vulnerabilities - from input sanitation to cross-site exploits, from authentication (and hashing, salting, password recovery, possibly data encryption) to resource access control.

What I mean is, these are things you would need to do in abstract, before starting development. So what about doing them in the abstract, and then applying them to an existing framework?

This would have several advantages:

• larger developer base. Given enough eyes, most bugs are shallow (even if events such as the SSL storm have tarnished that concept).
• already-(largely)-audited code base.
• a concrete, definite framework to which to apply the various security concepts and issues, short-circuiting the whole design-mock-build-test cycle.
• larger creative base - however brilliant you may be, you plus the others will always think of more possibilities than you alone. When doing the laundry list of things to do and watch for, this will be an invaluable help.
• the rest of the code is already there - you did focus on security, but the rest of the features and functionalities have been already developed.
• also, the rest of the code will probably supply some requirements just by being there - things that the framework need to be able to do. What if you designed a splendid, tightly secured system which later turned out to be unable (or able only with great difficulty and patching) to perform some key feature that in the beginning had been overlooked?

You do have the disadvantage of not being able to design the whole framework from the ground up, which could spawn some issues of its own.

But at least to start, I'd begin with a thorough examination of the security approach in an existing framework. And you get a lot of good karma with your chosen framework's guys; from a career standpoint, it's much more likely that you'll meet some potential employer requiring expertise with a known framework.