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.