Every programmer makes mistake and this is accepted globally as
unwritten truth. And most of the time developer doesn't know what
mistakes they are making. Here are my list of top mistakes to avoid.
1. Strategic aspects
Most programmers start coding the applications with the view of implementing the features from the default security perspective of "allowing all" the user to access and then will start to implement security for the elements (See Tactical aspects & suggestion on which elements to secure).
This happens across the board. Everything from operating systems to fat clients to web-based thin clients are constructed this way.
My strategic suggestion is to start coding from a default perspective of giving "deny all" access to every architectural element, every layer, every object, every method, every variable, etc., and construct them to be inaccessible to anything unless you expressly allow it. This will slow down your productivity a little (at least at first). However, once system is coded this way the delivered code and system will be vastly more secure.
Also, another rule for programmer is "Don't roll your own" or "Don't reinvent the wheel". 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 this rule.
2. Tactical aspects
In Tactical aspects, here are the common mistakes while coding security and things which every programmer should care about while coding the system.
Another bad habit programmers have is to leave huge chunk of non-required commented code. Almost everyone do this mistake thinking that we might need this in the future. Its always good to remove the commented code if its not required.
Case sensitivity
Some programming languages are case sensitive and some are not. But its always better to use the cases (upper or lower) of the variable and function name properly. This is also true while creating the hyperlinks and referencing the files. Windows is case insensitive so it doesn't matter if you use /program or /Program but it does matter in non-windows platforms. And when you are writing platform independent code always be careful about cases of the objects you use. Also, each programming language comes with its own convention like Java recommends to use camel case convention where starting letter of first word should be in lowercase and starting letter of remaining words should be in upper case. Java doesn't throw error if this convention is not used but it looks odd when this is not followed.
I hope you have enjoyed my list. Keep Coding and enjoy programming.
Lack of security
There are two aspects programmers forget while coding the system.1. Strategic aspects
Most programmers start coding the applications with the view of implementing the features from the default security perspective of "allowing all" the user to access and then will start to implement security for the elements (See Tactical aspects & suggestion on which elements to secure).
This happens across the board. Everything from operating systems to fat clients to web-based thin clients are constructed this way.
My strategic suggestion is to start coding from a default perspective of giving "deny all" access to every architectural element, every layer, every object, every method, every variable, etc., and construct them to be inaccessible to anything unless you expressly allow it. This will slow down your productivity a little (at least at first). However, once system is coded this way the delivered code and system will be vastly more secure.
Also, another rule for programmer is "Don't roll your own" or "Don't reinvent the wheel". 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 this rule.
2. Tactical aspects
In Tactical aspects, here are the common mistakes while coding security and things which every programmer should care about while coding the system.
- Not validating every bit of data from the client and user inputs
- Not considering filesystem permissions when working with files
- Not thinking about the database access permissions and keeping it too wide open for example, providing read-write access where only read is required
- Storing sensitive data in clear text like passwords, etc
- Not enforcing the strong passwords
- Thinking the user sees the system the programmer sees it
- Assuming system will never be attacked
- Thinking its Network Admin's responsibilities to provide security to the Network and applications
- Sending the sensitive data in query strings in websites
- Not taking care of hacking techniques like cross-scripting, SQL injections, etc
- Using third party libraries hastily without validating them
- Thinking login is the only page where security is needed.
- Creating backdoors for Administrative purposes
Improper Code Formatting
Easiest way to differentiate between experienced and inexperienced programmer is how they format their code. Most of the programming languages doesn't give error because of bad formatting of the code like indentation, use of white space, etc but it makes code extremely unmanageable if its not formatted properly. Programmers don't understand that indenting code makes one logical structure. By indenting (using tabs and spaces) functions, loop, conditions, etc makes code readable and manageable not only for others but for ourselves as well. Bad formatted code becomes error prone and difficult to debug.Another bad habit programmers have is to leave huge chunk of non-required commented code. Almost everyone do this mistake thinking that we might need this in the future. Its always good to remove the commented code if its not required.
Improper Variable and/or Function name
Sometimes its looks funny to us when some programmers use long function or variable names like fileForReading, but its actually good to have long meaningful name rather than short meaningless name. If we give meaningful names to variables and functions then its intent becomes very clear not only while coding for the first time but also during the maintenance. This will result in less errors as well because using non-meaningful name makes the probability of getting confused why this function and/or variable is created. Worst mistake developer can make is do the spelling mistakes while creating the variable names. It becomes difficult to remember the misspelt variable name and in high probability you will end up causing too many compiler errors. Its always better each developer makes its own naming convention as per their convenience as this will make them write the code faster and will reduce the compiler errors as well.Case sensitivity
Some programming languages are case sensitive and some are not. But its always better to use the cases (upper or lower) of the variable and function name properly. This is also true while creating the hyperlinks and referencing the files. Windows is case insensitive so it doesn't matter if you use /program or /Program but it does matter in non-windows platforms. And when you are writing platform independent code always be careful about cases of the objects you use. Also, each programming language comes with its own convention like Java recommends to use camel case convention where starting letter of first word should be in lowercase and starting letter of remaining words should be in upper case. Java doesn't throw error if this convention is not used but it looks odd when this is not followed.
Lack of commenting and/or overcommenting
Lack of commenting and doing over-commenting both are crime. Everyone should self-document their code where programmer explains the use of the variable, function and class names, and overall architecture and communicate the meaning of the code to other programmers and your future self without the need for lengthy comments. Whereas, over-commenting is also not required for example for code $a = $b; developer writes the comment like assigning value of $b to $a. Even layman programmer can understand what is being done here. These kind of commenting is useless. Instead programmers should write why this is done. We don't need to teach programing language in our code instead we should document how this program works
Not taking backup of your work
How many times does it happen to you that you lost important and good piece of work because you forgot to take backup or saved your programs and your machine restarted or malfunctioned. There are ample tools available in market now which gives you benefit like auto-saving, versioning control system, etc. While working on the open source projects I keep checking-in my code into SVN repository or Github which are free to use softwares.Not using debugging tools
Almost every programming language comes with powerful debugging tool which gives detail errors and help you identify the bugs in your code easily. Some programming languages doesn't comes with inbuilt debugging tools and in that case printing the statement on console or external debugging tools are quite useful. For example, while doing the web programming, I found developer tools like firebug extremely useful in not only finding the code issues but also the performance issues also.Start coding without understanding the programming language
Programming languages are no different than our languages which we speak. Programming languages have vocabulary, grammar and recommendations on how to use it. Major mistake newbies usually do is start coding the stuff without properly understanding the power of programming language and end up writing lengthy codes which in fact can be done in couple of lines and in no time.Coding without concentrating on the design
Most programmers are eager to start the coding for the new exciting project at hand. In this hurry they forget to understand the design of the program and end up creating something which is not customers wanted. Customer is king for any market and even though you wrote fantastic program which is not useful for customer then it would be of no use. Most programmers doesn't understand the users perspective and only think from the programmers perspective. Sometimes programmers codes features which are not asked by the customer. This creates lots of problem. This new feature is useful for the customer or not is another debate but if customer has not asked for this feature then it might not be on his priority list. Also, this features needs to be tested thoroughly so it consumes more time whereas this time was scheduled for something else. Also, most important because of free features given to customers, companies might be loosing good revenue opportunity. So, moral of the story is to stick to the design.I hope you have enjoyed my list. Keep Coding and enjoy programming.
Super Like :)
ReplyDelete