Some folks have advocated that security should be integrated into computer science coursework, throughout the curriculum. Suppose we are going to add one lecture on security, to a first course on programming. (Keep in mind that it is a very basic introductory course, so advanced topics are not appropriate.) What are the most important things that students should learn about security, in that context?

  • I think they should just add in safer programming tactics for someone who is just dabbling in it, to protect from simple things like buffer overflows. Then, if the student still shows an interest, the security can go more into depth. But that's just me =p
    – cutrightjm
    Commented Mar 16, 2012 at 16:39

5 Answers 5


If this is only going to be one lecture and this is their first programming class, I think input validation is the most viable topic to go over. Some of your students will already be struggling to understand how x = x + 1 (x equals x + 1) when x = 1 just the line before ... that is until they realize that it is an assignment statement.

Topics such as encryption, ssl, and sql injection need to be integrated in courses that have related projects so that they can be practically applied.

Input validation, however, is something that they will carry with them for the rest of their engineering career. It will help them mitigate the chances of their code being susceptible to buffer overflows, XSS, and (maybe)sql injection.


Security education should be contextual. There's not a lot to say about security when you're studying red-black trees or merge sort. But security should be a constant and pervasive factor as part of everything the student does.

Any security-related items should be required as a matter of course; bounds-checking and input sanitization, for example, should be absolutely required in all assignments. If the examiner can break the homework application by supplying invalid input, then points should be deducted. If array bounds aren't properly checked (assuming an unsafe language like C), then points off. It should't be sufficient to just have the thing pass the assigned test-case, it also has to be well-enough written that in a real-world scenario it wouldn't cause a disaster.

The students need to be used to always worrying about robustness and security the same way that chemistry students always should be worrying about lab safety. Security isn't something you study one semester and then move on.

If you're going to have a single lecture at the beginning about security, then it should primarily cover the security-related expectations that the students will be under. These expectations should be real-world expectations with respect to coding practices and should reflect the sort of vigilance that is always in the back of the mind for a good programmer.

This breaks down into several main areas, not all of which are appropriate for every language and every programming environment, here are a few that come to mind:

  • Language safety: An extremely big deal with C/C++, not so much with most everything else. Pointers, buffers, and that sort of thing fall into this category.

  • Input sanitization: Huge. Absolutely huge. I can't think of a single area in which this is not applicable.

  • Code clarity and documentation: Worth more than it sounds like. Many security vulnerabilities come from simple mistakes which stem from a misunderstanding of the code itself. The fewer mistakes you make, the better, even in the context of security.

    Also, I'd throw in principles like "DRY" into this mix, since security vulnerabilities sometimes are the result of assumptions being out-of-sync within the code. The more places you specify a single value, the more likely you'll forget to change one of them, which can lead to security vulnerabilities. I remember a "no magic numbers" homework rule when I studied CS, where all numeric constants had to be assigned a name. It's a good policy to have for many reasons.

  • Privilege isolation: A bit more esoteric, but important in certain scenarios. The principle of least privilege is something that students need to at least be familiar with, for example; but it's difficult to make part of your day-to-day activity.

  • Security-specific items: Such as password storage, encryption, and stuff like that. This is more informational than directly applicable with respect to schoolwork, so I'm not sure where it fits in with respect to lesson scheduling.

    It's important to learn about attacks like CSRF and token-stealing attacks in the more abstract sense, but probably not in an introductory course since it's a little advanced.


Im college student and I had that kind of course, first of they should teach how not to make mistakes in coding I mean, like protection against SQL Injection, or teach how to make own SSL connection and authorization, and a little about cryptology, I had like 7 sessions of that and all topics were explained pretty good... (I mean those topics weren`t just basics...) Now in my opinion there should be a lesson about how to protect against sql injection, and some stuff about cryptology like program called PARI..., those should be basic


Regardless of the language used in education there are a number of principles that hold true, so I'm going to steal them from here Security Ninja

  1. Input Validation - always check your inputs from untrusted sources
  2. Output Validation - make sure your output is appropriate for the destination (e.g. escaping HTML characters...)
  3. Error handling - dont give away too much information to the attacker
  4. Authentication & authorisation - know how to do this right
  5. Session Management
  6. Secure Communications
  7. Secure resources Management
  8. Secure Storage

Learn and apply those principles and any software developed afterwards will be of a much better quality.


Matt Bishop has written some articles and has a preface in his book which discusses this


You must log in to answer this question.

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