Page History

Top 10 Secure Coding Practices

1. Anchor
   validate input validate input

   Validate input. Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files [Seacord 05].

2. Anchor
   heed compiler warnings heed compiler warnings

   Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code [C MSC00-A, C++ MSC00-A]. Use static and dynamic analysis tools to detect and eliminate additional security

3. Wiki Markup

   <ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="b875df83-bf90-44b4-9810-e9fa5c03db32"><ac:parameter ac:name="">validate input</ac:parameter></ac:structured-macro> *Validate input.* Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software [vulnerabilities|BB. Definitions#vulnerability]. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files \[Seacord 05\].

4. Wiki Markup<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="b487d830-e447-4f00-8542-aea8d0289803"><ac:parameter ac:name="">heed compiler warnings</ac:parameter></ac:structured-macro> *Heed compiler warnings.* Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code \[[C MSC00-A|MSC00-C. Compile cleanly at high warning levels], [C+\+ MSC00-A|cplusplus:VOID Compile cleanly at high warning levels]\]. Use static and dynamic analysis tools to detect and eliminate additional security flaws.

5. Anchor
   design for security design for security

   Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set.

6. Wiki Markup

   <ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="10034611-bacf-4486-aea2-1a93b4febba7"><ac:parameter ac:name="">keep it simple</ac:parameter></ac:structured-macro> *Keep it simple.* Keep the design as simple and small as possible \[Saltzer 74, Saltzer 75\]. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex.

7. Wiki Markup

   <ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="ec61fa37-f426-4d64-98de-8d8cd7b40ae8"><ac:parameter ac:name="">default deny</ac:parameter></ac:structured-macro> *Default deny.* Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted \[Saltzer 74, Saltzer 75\].

8. Wiki Markup

   <ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="910273ce-c053-4bdf-ac94-1fd6049d6081"><ac:parameter ac:name="">apply least privilege</ac:parameter></ac:structured-macro> *Adhere to the principle of least privilege.* Every process should execute with the the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges \[Saltzer 74, Saltzer 75\].

9. Wiki Markup

   <ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="1ed57e07-40bc-4a99-8589-c79d86f4b271"><ac:parameter ac:name="">sanitize data</ac:parameter></ac:structured-macro> *Sanitize data sent to other systems.* Sanitize all data passed to complex subsystems \[[C STR02-A| STR02-C. Sanitize data passed to complex subsystems]\] such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem.

10. Wiki Markup

    <ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="e1eee02b-5eb4-4c63-addb-881cb96ecc9f"><ac:parameter ac:name="">practice defense in depth</ac:parameter></ac:structured-macro> *Practice* *defense in depth.* Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a [security flaw|BB. Definitions#security flaw] from becoming an exploitable vulnerability and/or limit the consequences of a successful [exploit|BB. Definitions#exploit]. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment \[Seacord 05\].

12. Anchor
    keep it simple keep it simple

    Keep it simple. Keep the design as simple and small as possible [Saltzer 74, Saltzer 75]. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex.

13. Anchor
    default deny default deny

    Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted [Saltzer 74, Saltzer 75].

14. Anchor
    apply least privilege apply least privilege

    Adhere to the principle of least privilege. Every process should execute with the the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges [Saltzer 74, Saltzer 75].

15. Anchor
    sanitize data sanitize data

    Sanitize data sent to other systems. Sanitize all data passed to complex subsystems [C STR02-A] such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem.

16. Anchor
    practice defense in depth practice defense in depth

    Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment [Seacord 05].

17. Anchor
    use quality assurance use quality assurance

    Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions [Seacord 05 Wiki Markup<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="fd429140-a43b-4447-9d85-8238459f88d4"><ac:parameter ac:name="">use quality assurance</ac:parameter></ac:structured-macro> *Use effective quality assurance techniques.* Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions \[Seacord 05\].

18. Anchor
    adopt secure coding standard adopt secure coding standard

    Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform.

...

1. Anchor
   define security requirements define security requirements

   Define security requirements. Identify and document security requirements early in the development life cycle and make sure that subsequent development artifacts are evaluated for compliance with those requirements. When security requirements are not defined, the security of the resulting system cannot be effectively evaluated.

2. Anchor
   model threats model threats

   Model threats. Use threat modeling to anticipate the threats to which the software will be subjected. Threat modeling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat mitigation strategies that are implemented in designs, code, and test cases [Swiderski 04 Wiki Markup<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="7e8430bb-d56f-4007-9daa-1c2fa4e9889d"><ac:parameter ac:name="">model threats</ac:parameter></ac:structured-macro> *Model threats.* Use threat modeling to anticipate the threats to which the software will be subjected. Threat modeling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat [mitigation|BB. Definitions#mitigation] strategies that are implemented in designs, code, and test cases \[Swiderski 04\].

Bonus Photograph

I found the following photograph on the Web, and I'm still trying to figure out who owns the rights to it. If you know, please comment below.

...

I like this photograph because it illustrates how the easiest way to break system security is often to circumvent it rather than defeat it (as is the case with most software vulnerabilities related to insecure coding practices).

References

Wiki Markup\[Saltzer 74\] Saltzer, J. H. "Protection and the Control of Information Sharing in Multics." _Communications of the ACM 17_, 7 (July 1974): 388-402.unmigrated-wiki-markup

\[Saltzer 75\] Saltzer, J. H. & Schroeder, M. D. "The Protection of Information in Computer Systems." _Proceedings of the IEEE 63_, 9 (September 1975), 1278-1308.unmigrated-wiki-markup

\[Seacord 05\] Seacord, R. _Secure Coding in C and C+\+_. Upper Saddle River, NJ: Addison-Wesley, 2006 (ISBN 0321335724).

Wiki Markup\[Swiderski 04\] Swiderski, F. & Snyder, W. _Threat Modeling_. Redmond, WA: Microsoft Press, 2004.