How do developers prevent critical data elements from being declared public?

What counts as a critical data element in code?

A critical data element is any field whose exposure or modification would materially affect security, privacy, integrity, or business logic. In practice, that includes secrets, tokens, authentication state, access decisions, and regulated or sensitive business data. If a value should only be used through a checked path, it should not be publicly reachable as a class member.

Once a field is public, any caller can read or overwrite it without passing through the rules your code intended to enforce. That is why the design decision is not just about style, it is about whether the object still controls its own state.

Why public fields undermine encapsulation and validation

Public fields bypass the control points that normally protect an object: getters, setters, constructors, validation routines, and invariants. When those values can be written directly, untrusted code can skip sanitisation, set inconsistent state, or expose information that should have stayed internal.

This matters most when the field represents security-relevant state, such as an API token, password-derived value, session marker, role flag, or account status. Even when the data itself is not secret, exposing it publicly can let other code make unsafe assumptions or alter behaviour in ways the original author did not intend.

Good design keeps the data private and exposes only the smallest useful interface. For read-only needs, provide controlled accessors. For changes, route updates through methods that can validate, normalise, log, or reject invalid input before state changes are committed.

For a broader view of how dangerous data exposure patterns are classified, the CWE Top 25 Guide is a useful starting point because it places encapsulation failures, sensitive information exposure, and missing validation in the wider weakness landscape.

Which code paths deserve the most scrutiny?

Review the places where public exposure often sneaks in: class fields, inherited members, serialised objects, auto-generated accessors, and convenience structures used in tests or scaffolding. A field may look harmless in one layer, then become dangerous when it crosses a trust boundary, is logged, or is copied into another component.

Inheritance deserves special attention because a superclass decision can make state visible to every subclass, including code you did not originally plan to trust. Serialisation also matters because it can rehydrate state without the usual constructor logic, leaving public members or mutable defaults available before checks run.

Developers should treat data classification as part of the design review, not an afterthought. The Data Classification Guide helps anchor the question of which fields need stricter handling, because “public in code” should never be confused with “public in business terms.”

When secrets or tokens are involved, the safest pattern is to avoid exposing the raw value unless the caller absolutely needs it and the interface can bound its use. Guidance in the OWASP Cheat Sheet Series reinforces this approach across secure coding, secrets handling, and input control.

Risk and Threat Considerations

Publicly accessible data members turn encapsulation failures into direct exposure. The usual failure mode is not dramatic exploitation at first, but silent loss of control: validation is bypassed, sensitive state is copied or logged, and downstream code starts trusting values that were never meant to be caller-controlled.

Failure mechanism: Untrusted code can read, overwrite, or clone a public field without going through the object's intended controls, which can expose secrets, corrupt security state, or break assumptions about object integrity.

Impact: The result can be credential disclosure, privilege or workflow tampering, inconsistent business logic, or insecure deserialisation and inheritance behaviour that persists across the application.

For environments that already treat sensitive data as a governed asset, public exposure is also a classification and handling failure. The problem is often amplified when developers assume that a field is safe because it is “only used internally,” while other modules, plugins, or generated code can still reach it.

Practitioner Guidance

What to verify: Check whether any field marked public can influence authorisation, identity state, cryptographic material, or security decisions. If it can, refactor so that the value is private and only exposed through methods that enforce the expected invariant.

Common mistake: Relying on naming conventions, comments, or team discipline instead of access modifiers and controlled interfaces. Code reviews should treat public mutable data as a defect unless there is a very specific, justified compatibility reason.

Practitioner takeaway: The key test is not whether a field is convenient to access, but whether making it public removes a control point the object needs to stay correct and secure.

Related resources from NHI Mgmt Group

• How do developers prevent external control of critical state data?
• What causes a critical data element to be declared public?
• Critical Data Element Declared Public
• How should security teams implement AI governance in environments where developers use public LLMs and internal data sources?