security-lang-cpp

Secure C++ Development

These rules apply to all C++ source and header files in the repository and aim to prevent memory corruption, resource leaks, undefined behavior, and security vulnerabilities through modern C++ best practices.

All violations must include a clear explanation of which rule was triggered and why, to help developers understand and fix the issue effectively.
Generated code must not violate these rules. If a rule is violated, a comment must be added explaining the issue and suggesting a correction.

1. Prevent Use After Free and Double Free (CWE-416, CWE-415)

• Rule: Use std::unique_ptr, std::shared_ptr, or std::weak_ptr instead of raw new/delete. Never access memory after it has been freed. Do not free the same memory twice. Smart pointers and RAII patterns automatically prevent use-after-free and double-free vulnerabilities.

2. Avoid Raw Pointers for Ownership

• Rule: Do not use raw pointers (T*) to express ownership. Use smart pointers or containers. Raw pointers should only be used for non-owning references. Always verify non-owning pointers are not null before dereferencing.

3. Initialize All Variables (CWE-824)

• Rule: Always initialize variables, including pointers, at declaration. Use uniform initialization {} to prevent narrowing conversions. Never leave objects in an indeterminate state. Accessing uninitialized pointers or variables leads to undefined behavior and potential security vulnerabilities.

4. Prevent Use-After-Move

• Rule: After moving from an object with std::move(), do not access its value unless it has been reassigned. Document moved-from states clearly.

5. Prevent Out-of-Bounds Write and Read (CWE-787, CWE-125, CWE-119, CWE-676)

• Rule: Use STL containers (std::vector, std::array, std::string, std::span for views) with bounds-checked access (.at()) instead of C-style arrays and manual index looping. When converting legacy C-style arrays, use std::to_array (C++20) to preserve size information and enable bounds-checked access. Never use potentially dangerous functions like strcpy, sprintf, gets, scanf, or other unbounded string functions. Prefer standard algorithms with .at() over unchecked operator[] in security-critical code. Out-of-bounds memory access is a leading cause of exploitable vulnerabilities.