[security] What should every programmer know about security?

I am an IT student and I am now in the 3rd year in university. Until now we've been studing a lot of subjects related to computers in general (programming, algorithms, computer architecture, maths, etc).

I am very sure that nobody can learn every thing about security but sure there is a "minimum" knowledge every programmer or IT student should know about it and my question is what is this minimum knowledge?

Can you suggest some e-books or courses or anything can help to start with this road?

This question is related to security

The answer is


  • Remember that you (the programmer) has to secure all parts, but the attacker only has to succeed in finding one kink in your armour.
  • Security is an example of "unknown unknowns". Sometimes you won't know what the possible security flaws are (until afterwards).
  • The difference between a bug and a security hole depends on the intelligence of the attacker.

Security is a process, not a product.

Many seem to forget about this obvious matter of fact.


The importance of secure defaults in frameworks and APIs:

  • Lots of early web frameworks didn't escape html by default in templates and had XSS problems because of this
  • Lots of early web frameworks made it easier to concatenate SQL than to create parameterized queries leading to lots of SQL injection bugs.
  • Some versions of Erlang (R13B, maybe others) don't verify ssl peer certificates by default and there are probably lots of erlang code that is susceptible to SSL MITM attacks
  • Java's XSLT transformer by default allows execution of arbitrary java code. There has been many serious security bugs created by this.
  • Java's XML parsing APIs by default allow the parsed document to read arbitrary files on the filesystem. More fun :)

Every programmer should know how to write exploit code.

Without knowing how systems are exploited you are accidentally stopping vulnerabilities. Knowing how to patch code is absolutely meaningless unless you know how to test your patches. Security isn't just a bunch of thought experiments, you must be scientific and test your experiments.


Just wanted to share this for web developers:

security-guide-for-developers
https://github.com/FallibleInc/security-guide-for-developers


For general information on security, I highly recommend reading Bruce Schneier. He's got a website, his crypto-gram newsletter, several books, and has done lots of interviews.

I would also get familiar with social engineering (and Kevin Mitnick).

For a good (and pretty entertaining) book on how security plays out in the real world, I would recommend the excellent (although a bit dated) 'The Cuckoo's Egg' by Cliff Stoll.


I suggest reviewing CWE/SANS TOP 25 Most Dangerous Programming Errors. It was updated for 2010 with the promise of regular updates in the future. The 2009 revision is available as well.

From http://cwe.mitre.org/top25/index.html

The 2010 CWE/SANS Top 25 Most Dangerous Programming Errors is a list of the most widespread and critical programming errors that can lead to serious software vulnerabilities. They are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

The Top 25 list is a tool for education and awareness to help programmers to prevent the kinds of vulnerabilities that plague the software industry, by identifying and avoiding all-too-common mistakes that occur before software is even shipped. Software customers can use the same list to help them to ask for more secure software. Researchers in software security can use the Top 25 to focus on a narrow but important subset of all known security weaknesses. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software.


  1. Why is is important.
  2. It is all about trade-offs.
  3. Cryptography is largely a distraction from security.

I would add the following:

  • How digital signatures and digital certificates work
  • What's sandboxing

Understand how different attack vectors work:

  • Buffer overflows/underflows/etc on native code
  • Social engineerring
  • DNS spoofing
  • Man-in-the middle
  • CSRF/XSS et al
  • SQL injection
  • Crypto attacks (ex: exploiting weak crypto algorithms such as DES)
  • Program/Framework errors (ex: github's latest security flaw)

You can easily google for all of this. This will give you a good foundation. If you want to see web app vulnerabilities, there's a project called google gruyere that shows you how to exploit a working web app.


when you are building any enterprise or any of your own software,you should just think like a hacker.as we know hackers are also not expert in all the things,but when they find any vulnerability they start digging into it by gathering information about all the things and finally attack on our software.so for preventing such attacks we should follow some well known rules like:

  • always try to break your codes(use cheatsheets & google the things for more informations).
  • be updated for security flaws in your programming field.
  • and as mentioned above never trust in any type of user or automated inputs.
  • use opensource applications(their most security flaws are known and solved).

you can find more security resource on the following links:

for more information google about your application vendor security flows.


A good starter course might be the MIT course in Computer Networks and Security. One thing that I would suggest is to not forget about privacy. Privacy, in some senses, is really foundational to security and isn't often covered in technical courses on security. You might find some material on privacy in this course on Ethics and the Law as it relates to the internet.


Also be sure to check out the OWASP Top 10 List for a categorization of all the main attack vectors/vulnerabilities.

These things are fascinating to read about. Learning to think like an attacker will train you of what to think about as you're writing your own code.


Salt and hash your users' passwords. Never save them in plaintext in your database.


You should know about the three A's. Authentication, Authorization, Audit. Classical mistake is to authenticate a user, while not checking if user is authorized to perform some action, so a user may look at other users private photos, the mistake Diaspora did. Many, many more people forget about Audit, you need, in a secure system, to be able to tell who did what and when.


Rule #1 of security for programmers: Don't roll your own

Unless you are yourself a security expert and/or cryptographer, always use a well-designed, well-tested, and mature security platform, framework, or library to do the work for you. These things have spent years being thought out, patched, updated, and examined by experts and hackers alike. You want to gain those advantages, not dismiss them by trying to reinvent the wheel.

Now, that's not to say you don't need to learn anything about security. You certainly need to know enough to understand what you're doing and make sure you're using the tools correctly. However, if you ever find yourself about to start writing your own cryptography algorithm, authentication system, input sanitizer, etc, stop, take a step back, and remember rule #1.


The Web Security team at Mozilla put together a great guide, which we abide by in the development of our sites and services.