Editing Defensive programming (section)

===Other ways of securing code===
* One of the most common problems is unchecked use of constant-size or pre-allocated structures for dynamic-size data{{cn|date=December 2023}} such as inputs to the program (the [[buffer overflow]] problem). This is especially common for [[string (computer programming)|string]] data in [[C (programming language)|C]]{{cn|date=December 2023}}. C library functions like <code>gets</code> should never be used since the maximum size of the input buffer is not passed as an argument. C library functions like <code>scanf</code> can be used safely, but require the programmer to take care with the selection of safe format strings, by sanitizing it before using it.
* Encrypt/authenticate all important data transmitted over networks.  Do not attempt to implement your own encryption scheme, use a [[Cryptography standards|proven one]] instead. Message checking with a hash or similar technology will also help secure data sent over a network.

====The three rules of data security====
* All [[data]] is important until proven otherwise.
* All data is tainted until proven otherwise.
* All code is insecure until proven otherwise.
** You cannot prove the security of any code in [[userland (computing)|userland]], or, more commonly known as: ''"never trust the client"''.
These three rules about data security describe how to handle any data, internally or externally sourced:

'''All data is important until proven otherwise''' - means that all data must be verified as garbage before being destroyed.

'''All data is tainted until proven otherwise'''   - means that all data must be handled in a way that does not expose the rest of the runtime environment without verifying integrity.

'''All code is insecure until proven otherwise'''  - while a slight misnomer, does a good job reminding us to never assume our code is secure as bugs or [[undefined behavior]] may expose the project or system to attacks such as common [[SQL injection]] attacks.

====More Information====
* If data is to be checked for correctness, verify that it is correct, not that it is incorrect. 
* [[Design by contract]]
* [[Assertion (computing)|Assertions]] (also called '''assertive programming''')
* Prefer [[Exception handling|exceptions]] to return codes
** Generally speaking, it is preferable{{According to whom|date=December 2023}} to throw exception messages that enforce part of your [[application programming interface|API]] [[Design by contract|contract]] and guide the developer instead of returning error code values that do not point to where the exception occurred or what the program stack looked liked, Better logging and exception handling will increase robustness and security of your software{{cn|date=December 2023}}, while minimizing developer stress{{cn|date=December 2023}}.