The question Do you actively think about security when coding? asks about security mindset while programming.

Obviously, a developer does need to think about security while coding — SQL injection, password security, etc.

However, as far as the real, fully-formed security, especially the tricky problems that may not be immediately obvious, should I be concerned with tackling these throughout the development process, or should it be a step of its own in later development?

I was listening to a podcast on Security Now and they mentioned about how a lot of the of the security problems found in Flash were because when Flash was first developed it wasn't built with security in mind (because it didn't need to) — therefore Flash has major security flaws at its core.

I know that no one would want to actively disagree with "think security first" as a best practice, but many companies do not follow best practices. So, what is the correct approach to balance between needing to get the product done and developing it securely?


4 Answers 4


At work we have a list of simple/standard things that we aren't supposed to do. Like non-parameterized queries and such. We have to review our code and are supposed to get someone else to review it as well to make sure none of the no-nos are implemented. After you've been through that a couple of times, you can't help but think of security while you code. In my opinion, you should code for security while coding for functionality. All the time. Very few exceptions.

  • Good answer! That's what I was thinking but just needed clarification that other people are on the same frame of mind. On a side note I had a look at your Chinese reader a while back, the one and only Trevor
    – MattyD
    Jun 27, 2011 at 0:26
  • @MattyD. Haha. That's great. Small world!
    – Trevor
    Jun 28, 2011 at 0:10

Firstly with any application that is going to be available to the public or run on public-facing machines, I try to design for security on the start. What risks does this application potentially expose? How can these be mitigated? What is the worst outcome that could arise from a security compromise of this application and what can be done to minimise the pain of that outcome?

If you design to be secure from the very start, you have to think about it less when you are actually typing. Of course there are practices that you need to follow to prevent the most common attacks, but if the application is structured to behave in a more secure way from the very start, it will be far easier to maintain code security later.

  • +1 As part of the required design documents for any new feature my team writes, we are required to specifically consider security. Even for features for internal tools, it is good to think ahead-of-time about the security requirements (any data that ends up getting passed externally is scrubbed of certain kinds of private information, for example). Jun 27, 2011 at 19:11

Security is like performance.

You can't get a can of security and sprinkle it over the software later.

When people design products and don't think of the ilities you get problems.

  • security
  • reliability
  • supportability
  • performance ( scalability)

Now when you think that security isn't a requirement one has to ask: where is the software used. If the answer isn't on a ROM cartridge on a machine with no external media or network connection, then your requirements analysis is a little lacking.

If a customer runs your software they would expect that your software does not expose their other data to theft or damage. They could also reasonably expect that their computer and network don't get used by some hostile botnet as a result of security flaws in your product.

That expectation of security is probably appropriate for almost all software. The language I've used is intentionally legalistic, as we are talking about issues that a customer might try suing you or your employer for.

If someone can think of some software that can be insecure up front, can you comment ?


There are two kinds of security problems:

  • Localized problems, like buffer overflow resulting from a lack of array bounds checking or SQL injections resulting from confusing queries with strings. These can be solved by using good programming tools (good type systems will catch many of these). When found, they can be fixed easily; but when there's one there are usually many similar ones.
  • Deep design issues, like not segregating permissions enough or committing to leaky protocols. Getting these right require intelligent planning. When found, they are often a nightmare to fix, because you need to rewrite large swathes of code or to introduce major incompatibilities.

Not designing for security is like building a house of straw. It works until the big bad wolf comes along, and then you lose. This doesn't mean you should always design for security, wolfproofness isn't always required. But you don't turn a house of straw into a house of bricks by bolting security on; it's a whole different house. Similarly, if you don't design for security from day 1, securing will be more of a complete redesign than a light evolution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.