CWE-547

Use of Hard-coded, Security-relevant Constants. [Bad-Coding-Practices, Improper-Adherence-To-Coding-Standards]

Required inputs: IR

The product uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change. If the developer does not find all occurrences of the hard-coded constants, an incorrect policy decision may be made if one of the constants is not changed. Making changes to these values will require code changes that may be difficult or impossible once the system is released to the field. In addition, these hard-coded values may become available to attackers if the code is ever disclosed.

Demonstrative Examples

Example 1

The usage of symbolic names instead of hard-coded constants is preferred.

The following is an example of using a hard-coded constant instead of a symbolic name.

Example Language:C
    char buffer[1024];
    ...
    fgets(buffer, 1024, stdin);

If the buffer value needs to be changed, then it has to be altered in more than one place. If the developer forgets or does not find all occurrences, in this example it could lead to a buffer overflow.

Example Language:C
    enum { MAX_BUFFER_SIZE = 1024 };
    ...
    char buffer[MAX_BUFFER_SIZE];
    ...
    fgets(buffer, MAX_BUFFER_SIZE, stdin);

In this example the developer will only need to change one value and all references to the buffer size are updated, as a symbolic name is used instead of a hard-coded constant.

Excerpts from CWE [https://cwe.mitre.org], Copyright (C) 2006-2026, the MITRE Corporation. See section 9.4. "3rd-Party Licenses" in the documentation for full details.

Possible Messages

Key	Text	Severity	Disabled
magic_number	Use of magic literal.	None	False
magic_number_without_token	Use of magic literal.	None	False
possible_magic_number	Potential use of magic literal.	None	False

Options

• This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity

• The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions

allow_nonconst_variable_initialization

allow_nonconst_variable_initialization : bool = False

If set to true, allow magic numbers in the initialization of variables, even if the variable is not const. This option only applies to the initialization as part of the variable declaration, not to any later assignments.

 

allowed

allowed : set[float] = {0.0, 1.0, 2.0}

Literal values that are ok.

 

allowed_contexts

allowed_contexts : set[bauhaus.ir.PIR_Class_Name | typing.Callable[[bauhaus.ir.Node], bool]] = set()

Optional set of PIR classes or functions ((node) -> bool) for allowed contexts, e.g. Case_Label.

 

exceptions

exceptions : typing.Callable[[bauhaus.ir.Node], bool] | None = None

Optional predicate to filter out cases that should be allowed as an exception. The predicate takes a literal node and returns True if the given node is such an exception.

 

exclude_pp_literals

exclude_pp_literals : bool = True

If true, literals in conditions of #if are ignored.

 

exclude_single_uses

exclude_single_uses : bool = False

If true, report only literals used more than once.