Recently, a website related to our university was hacked along with many others. This led to a general discussion1 on how to secure the website in the future.

Anyway, there is one point that was discussed quite a bit. Assuming that one is a competent developer, is it better to "code from scratch" (write your own homebrew framework to host the site), or is it better to use a popular framework that is freely available?

I understand that this may not have a simple "yes/no" answer. I'm looking for some explanation as to when each option is favorable. Or a detailed comparison of the two options would be nice as well.

1 If anyone wants, this is the mailing list thread, but it talks about other things as well and you probably don't want to look at it ;-)

  • 5
    If you're given infinite time, you can create an infinitely secure solution that will have infinitesimally small utility. Feb 17, 2013 at 19:10

5 Answers 5


You certainly want your code to be written by the most skilled developer possible, but that's not enough. Even the most competent developers make mistakes (though less competent ones obviously tend to make more mistakes).

To get relatively mistake-free code and algorithms, you want to start out with the cleanest code possible, but that's only half the process. The best way to eliminate faults is to have as many skilled developers as possible comb through the code looking for them. This holds true for code as much as it does for algorithms. Your solution needs to be widely vetted by the most experienced people possible.

Where you start -- the skill level of the original developer -- is just the starting point. After sufficient review, it doesn't really matter how skilled the original developer was.

So here's the key: the security value in any code is in how well-vetted it is. Whether it was written by you, by a renowned cryptographer, a large corporation, or nobody in particular, all that matters is how many skilled eyes have scrutinized the code.

Such a rule tends to favor established frameworks over homespun solutions. But established is not necessarily the same as vetted, which is part of why many security experts tend to favor open-source solutions: it's difficult for an open-source project to become popular without it being subjected to a certain amount of scrutany.

  • 4
    It's also worth mentioning that you can pay companies to perform a code security review, either from an external point of view (black box) or from the source itself (white box). These are often useful because they spend all day looking for security holes in products, and usually have very sharp intuition when it comes to spotting areas where potential holes might be.
    – Polynomial
    Feb 18, 2013 at 11:49
  • also worth noting: even if you don't use a "framework", it's unlikely you're going to write every component yourself - for example, many apps written without a framework use a third-party e-mail component, third-party password cryptography, etc. - hence, many of the same concerns mentioned by others on this page apply with or without a framework. It's really all about taking ownership of the code you use: whether your team wrote it or not, own it: know it well, maintain it, and when you integrate third-party code (frameworks or otherwise) release maintenance changes back to the community. Feb 18, 2013 at 14:28

For a homebrew framework, a competent programmer is not sufficient. You need a competent programmer who has time to devote to both implementation and subsequent maintenance, and who will still do it ten years from now. This can be done, but not really in a University context where students come and go.

If you stick to an established framework, then you benefit from the security updates and general work from the framework maintenance team, which will make your task easier.

The one point to remember is that a homebrew framework does not, by itself, provide security; it just gives a feeling of security. The reasoning usually goes along the lines of: "since we have a homebrew framework, we do not suffer from the known bugs and weaknesses of an established framework, and the attacker will never guess where our own bugs are". This reasoning is flawed: the attacker already knows your code, possibly better than you. Especially in a university, which, by definition, hosts a lot of technologically savvy people with an adventurous frame of mind, flexible morals, and, as a rule, way more free time and available computing power than can be considered healthy.

So you should use an established framework.

  • Of note is that even an established framework still needs to be cared for, updated, looked after, monitored... ten years from now, ie. when they are no longer sexy, no longer the flavor of the day, and no one in the University wants anything to do with them anymore. Jun 7, 2016 at 8:15

You have two concerns:

  1. "Drive-by hackers" who delete your data, stop your web server functioning by exploiting thousands web sites at once.
  2. "Targeting hackers" who want to access to your web server specifically for "higher gains" whatever that could be.

First isn't an issue as long as you have solid backup, update, recovery plans in place. It will beat the cost of writing a framework unless you get hacked every other day.

The second one won't matter even if you DON'T use a framework. Because if the incentive is high enough, anything goes, including social hacking, buying zero-day exploits from black market etc. What you need to do is to lower the incentive. Isolate valuable data from web server and your framework's weaknesses are not important anymore.


The single biggest problem with a homebrew framework: Too few experts in the codebase.

Writing one's own framework is good fun (well, it is for the kind of coder that enjoys that kind of thing), but unless the ownership of the code is shared widely, it is a dangerous path to take.

I've worked in several places where they had written their own framework libraries. typically, the framework itself has been written almost entirely by one or two developers. The bosses are convinced that the framework code was a valuable asset, and the lead developers who know the code inside out are virtually irreplaceable.

The problem is that in every case I've seen, the code is full of bugs, security holes and poor practice. When the lead developer finally leaves, his successors are left to pick up the pieces. Sometimes they just battle on with the existing code; sometimes they undertake a large-scale re-engineering project; sometimes they switch to a third party framework.

The other problem that typically happens is that technology and user requirements move on. If you've written your own framework, you need to keep working on it constantly to keep it up-to-date. This is fine if the framework is your main project, but if it's just your back-end code, it will eat your time that would be better spent working on your actual project.

Finally, security. This is the big one, really. Many, many competent developers have written code that is insecure. In fact, if we're honest, we all have. Java wasn't written by incompetents, and yet Oracle had to issue a patch for fifty security holes this week. Every other piece of software you could name has had holes in it as well, and probably still has holes. By writing your own framework, you are categorically not going to be writing something more secure than any of the well known third-party frameworks. In fact its likely to be significantly worse, and you won't have the resources to go looking for security bugs. You'll have "security by obscurity" because no-one will have seen your code, but you only need to google that phrase to see what the security world thinks about that.

So in summary, I would say No; a home-brew framework is not a good idea.

Go ahead and write one anyway -- it is a great learning exercise -- but don't expect it to be as good as the frameworks already out there. If it was that easy, there wouldn't be any need for the existing libraries.


As outlined by others, the supported, vetted and maintained framework will almost always be better than a 'homebrew' solution. This is especially true in University context where work is often done initially as a project and then lingers around with insufficient funding and support for years afterwards. Provided security paches are applied to the ramework, you can at least maintain some level of confidence. The same cannot be said for a homebrew system. Given that security is an evolving and moving feast, you need this.

The one warning I would have concerning established frameworks is ensuring you choose the right framework for the task. Some frameworks are huge, extremely complex and require specialised knowledge and experience to use correctly. A secure and well designed framework will be of no benefit if it is implemented or used by inexperienced developers. In addition to considering the security aspects of your framework, also consider the skill sets of your developers and look for a framework which provides just the functionality you want and not a lot of additional features you don't need and probably won't configure correctly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .