Open-source web-apps: should code be readily available?

If you’re a student like me, I assume you realise the importance of letting everybody know your potential. We are all learners, but we need to set ourselves apart from others in order to fight for the best jobs out there. Before GitHub, you needed to own and maintain a website in order to show off your cool projects. Now, recruiters and senior engineers alike can watch your repos and see for themselves if you’d be a good addition to the team.

I’m guessing we all want the best jobs out there, yet only some will get them.

In order to show off just how great we (the students) are, we build portfolios by uploading projects on GitHub. People can use our projects if they are useful enough, and we get the feeling we’ll look good because of that awesome code we wrote on important projects. There are many corporations that take this into consideration, and I don’t condone this approach of seeking talented people, but I also don’t think a GitHub profile says how good of an asset you are for a company.

Here’s an example: one dev might have a reputable profile with a substancial amount of contributions, but he/she could be a terrible team player. Or, on the other hand, another dev might have little to no contributions online, but eventually grows up to be a great developer (also assuming that college doesn’t only teach you how to write code and design algorithms).


I’m learning how to build web pages in my spare time, and I like it more with every new thing I learn. So let’s assume that I’d like to build my own portfolio of web-app projects in order to be an interesting hire for a big company one day. The obvious thing to do would be to keep my front-end code available on GitHub, so that every one could look at my terrible JavaScript. But there is a good argument against that. For instance, if I had a page I was working on, everyone would be able to see it, whether I’d like it or not. Sure, I could use branches in order to hide my work in progress, but it’s not a solution at all.

And how about my back-end code? Should I really hand out my server code in a silver platter?

I know we are getting into the whole discussion of security by obscurity, but there is a reason why securityheaders.io told me to remove any references to what software I’m running. It’s because attackers will have a harder time guessing what web-server I’m running, and more importantly, what version is it. Stripping that header away makes me a harder target. If NGINX has an exploitable vulnerability in its latest release and someone wants to take advantage of it, they might have bots sniff out server headers in search for NGINX servers. Removing that vendor reference might just save your bacon! Before you get all angry, I do agree that hiding the server version doesn’t make me any more safe from a direct attack. And if I get targeted directly.. Well, I might have the server header anyways.

This reminds me of a good talk from Tom Scott, you should check it out.

Turning our attention to the back-end code, by using a public GitHub repository I would in fact be opening the door to a vulnerability on my own code. Inexperience with a certain language is no excuse to write vulnerable code but it’s just something that happens sometimes, so I’d face the chance of getting PWND one day. But this option is interesting nonetheless. I would almost be wagering my code is secure enough to be posted in the wild. But from a security standpoint, how bad is it to have your server code exposed somewhere? In this case I’d say it depends on the attacker and on the target. What target are you really?

  • If you’re just a student and you’re starting out, you’re not really an interesting target. I mean, what would an attacker do with your server after compromising it? Do you store user accounts or anything that might translate into profit? If not, then I’d say you should put your code out there and show your worth.
  • On the other hand, if you own a startup and someone could benefit from the data you’re storing, than I’d advise to keep your code in-house only, and publish it only after having a couple of security audits. Only then would I feel safe to publish server code.

Finally, addressing the attacker, I’d say there are small sharks and big sharks. Small sharks: script kiddies with a little extra talent up to an experienced black hat will attack using easy vectors like vulnerable software versions, and in a bad luck scenario, a really obvious security vulnerability on your code. If you patch your software often enough and you make an effort to keep your security settings updated you should not fear these types of attacks. Big sharks however, are a big pain in the butt. I’m talking about the Syrian Electronic Army, other black hat hacker groups and government agencies will probably find other ways in. I’m talking about zero-day vulnerabilities, which are your nightmare and everyone else’s. Let’s exclude passive attacks like breaking communication protocols, since those are too hard to detect and, to be honest, are really not your concern.

There is nothing that can prevent you from being breached by a zero-day unless you know about it and you have fixed it yourself (highly unlikely, I’d say). However, every time zero-days are used the chance that the vulnerability gets discovered increases, because developers that have been targeted will try to find out how it happened. So in short, attackers will use that zero-day vulnerability on high-value targets, which begs the question: If you’re a high value target, why are you taking security suggestions from a one-year old? 🤔

My point is that once you think you’re big enough to get attacked by bigger sharks, consider hiring a security consultant or a really good security team, but don’t expect immunity. If you’d like to go further in your security endeavours, I’d advise making sure once you get breached the attackers aren’t able to take everything. Aside from simple security configurations, consider storing different things in different servers and have each server running on different platforms… 😉

To end in a good note, I’d like to leave you with a quote from our lord and saviour, Bruce Schneier:

The mantra of any good security engineer is: ‘Security is a not a product, but a process.’ It’s more than designing strong cryptography into a system; it’s designing the entire system such that all security measures, including cryptography, work together.

Hope you liked it, and I’ll see you on the next one.