{{Short description|Software development methodology}} {{Multiple issues| {{More citations needed|date=September 2017}} {{More footnotes|date=September 2010}} }}
'''Secure coding''' is the practice of developing computer software in such a way that guards against the accidental introduction of security vulnerabilities. Defects, bugs and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities.<ref name="bss2001">{{Cite book| last = Viega | first = John |author2=Gary McGraw | title = Building Secure Software: How to Avoid Security Problems the Right Way | year = 2001 | publisher = MAddison-Wesley Professional | pages = 528 | isbn = 978-0201721522 }}</ref> Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment.<ref>{{Cite book|last1=Taylor|first1=Blair|last2=Azadegan|first2=Shiva|title=Proceedings of the 3rd annual conference on Information security curriculum development |chapter=Threading secure coding principles and risk analysis into the undergraduate computer science and information systems curriculum |date=2006-09-22|chapter-url=https://doi.org/10.1145/1231047.1231053|series=InfoSecCD '06|location=Kennesaw, Georgia|publisher=Association for Computing Machinery|pages=24–29|doi=10.1145/1231047.1231053|isbn=978-1-59593-437-6|s2cid=2452783}}</ref>
Some scholars have suggested that in order to effectively confront threats related to cybersecurity, proper security should be coded or "baked in" to the systems. With security being designed into the software, this ensures that there will be protection against insider attacks and reduces the threat to application security.<ref>{{Cite journal |last=Russell L |first=Jones |date=Dec 2004 |title=Secure Coding: Building Security into the Software Development Life Cycle |url=https://www.proquest.com/docview/229507883 |journal=Information Systems Security|id={{ProQuest|229507883}} }}</ref> Implementing secure coding practices is part of the secure by design approach to security engineering.
== Buffer-overflow prevention == Buffer overflows, a common software security vulnerability, happen when a process tries to store data beyond a fixed-length buffer. For example, if there are 8 slots to store items in, there will be a problem if there is an attempt to store 9 items. In computer memory the overflowed data may overwrite data in the next location which can result in a security vulnerability (stack smashing) or program termination (segmentation fault).<ref name="bss2001"/>
An example of a C program prone to a buffer overflow is <syntaxhighlight lang="c++"> #include <string.h>
#define SMALL 50
void vulnerable_function(char* large_user_input) { char dst[SMALL]; strcpy(dst, large_user_input); } </syntaxhighlight> If the user input is larger than the destination buffer, a buffer overflow will occur.
To fix this unsafe program, use strncpy to prevent a possible buffer overflow. <syntaxhighlight lang="c++"> #include <string.h>
#define BUF_SIZE 100
void secure_function(char* user_input) { char dst[BUF_SIZE]; // copy a maximum of BUF_SIZE bytes strncpy(dst, user_input, BUF_SIZE); // set the last character in the buffer to NUL. dst[BUF_SIZE - 1] = '\0'; } </syntaxhighlight> Another secure alternative is to dynamically allocate memory on the heap using malloc. <syntaxhighlight lang="c++"> #include <stdlib.h> #include <string.h>
char* secure_copy(char* src) { size_t len = strlen(src); char* dst = (char*)malloc(len + 1); if (dst) { strncpy(dst, src, len); // append null terminator dst[len] = '\0'; } return dst; } </syntaxhighlight> In the above code snippet, the program attempts to copy the contents of <code>src</code> into <code>dst</code>, while also checking the return value of <code>malloc()</code> to ensure that enough memory was able to be allocated for the destination buffer.
== Format-string attack prevention == A Format String Attack is when a malicious user supplies specific inputs that will eventually be entered as an argument to a function that performs formatting, such as {{mono|printf()}}. The attack involves the adversary reading from or writing to the stack.
The C printf function writes output to stdout. If the parameter of the printf function is not properly formatted, several security bugs can be introduced. Below is a program that is vulnerable to a format string attack. <syntaxhighlight lang="c++"> #include <stdio.h>
void vulnerable_print(char* malicious_input) { printf(malicious_input); } </syntaxhighlight>A malicious argument passed to the program could be "%s%s%s%s%s%s%s", which can crash the program from improper memory reads.
== Integer-overflow prevention == Integer overflow occurs when an arithmetic operation results in an integer too large to be represented within the available space. A program which does not properly check for integer overflow introduces potential software bugs and exploits.
Below is a function in C++ which attempts to confirm that the sum of x and y is less than or equal to a defined value MAX: <syntaxhighlight lang="c++"> #define MAX 5000
bool sum_is_valid_flawed(unsigned int x, unsigned int y) { unsigned int sum = x + y; return sum <= MAX; } </syntaxhighlight> The problem with the code is it does not check for integer overflow on the addition operation. If the sum of x and y is greater than the maximum possible value of an <code>unsigned int</code>, the addition operation will overflow and perhaps<!-- Note that an overflow will not always result in the calculated sum being less than MAX; MAX might be relatively small and both x and y relatively big, so even an overflow might still be greater than MAX. Example: x=y=UINT_MAX, MAX=1000000. --> result in a value less than or equal to MAX, even though the sum of x and y is greater than MAX.
Below is a function which checks for overflow by confirming the sum is greater than or equal to both x and y. If the sum did overflow, the sum would be less than x or less than y. <syntaxhighlight lang="c++"> #define MAX 5000
bool sum_is_valid_secure(unsigned int x, unsigned int y) { unsigned int sum = x + y; return sum >= x && sum >= y && sum <= MAX; } </syntaxhighlight>
== Path traversal prevention == {{Main|Directory traversal attack}} Path traversal is a vulnerability whereby paths provided from an untrusted source are interpreted in such a way that unauthorised file access is possible.
For example, consider a script that fetches an article by taking a filename, which is then read by the script and parsed. Such a script might use the following hypothetical URL to retrieve an article about dog food: <nowiki>https://www.example.net/cgi-bin/article.sh?name=dogfood.html</nowiki> If the script has no input checking, instead trusting that the filename is always valid, a malicious user could forge a URL to retrieve configuration files from the web server: <nowiki>https://www.example.net/cgi-bin/article.sh?name=../../../../../etc/passwd</nowiki> Depending on the script, this may expose the /etc/passwd file, which on Unix-like systems contains (among others) user IDs, their login names, home directory paths and shells. (See SQL injection for a similar attack.)
== Regulatory drivers == Secure coding practices are increasingly mandated by regulatory frameworks governing the development and maintenance of software systems that process sensitive data. The Health Insurance Portability and Accountability Act (HIPAA) Security Rule requires covered entities to protect the integrity of protected health information through technical safeguards under 45 CFR 164.312(c)(1) and to implement mechanisms to authenticate electronic protected health information under 45 CFR 164.312(c)(2).<ref>{{cite web |title=Security Standards: Technical Safeguards |url=https://www.hhs.gov/hipaa/for-professionals/security/guidance/technical-safeguards/index.html |publisher=U.S. Department of Health and Human Services |access-date=April 1, 2026}}</ref> The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 Requirement 6.2 mandates that custom software is developed securely, including training developers in secure coding techniques (6.2.2), reviewing custom code for vulnerabilities before release (6.2.3), and addressing common software attacks in development practices (6.2.4).<ref>{{cite web |title=PCI DSS v4.0 |url=https://www.pcisecuritystandards.org/document_library/ |publisher=PCI Security Standards Council |date=March 2022 |access-date=April 1, 2026}}</ref> == See also == * Application security * Defensive programming * Security bug
== Notes == {{Reflist}}
== References == * {{Cite book| last = Taylor | first = Art |author2=Brian Buege |author3=Randy Layman | title = Hacking Exposed J2EE & Java | year = 2006 | publisher = McGraw-Hill Primis | pages = 426 | isbn = 0-390-59975-1 }}
{{Computer security}} {{DEFAULTSORT:Secure Coding}} Category:Computer security