CWE-487, Reliance on Package-level Scope, covers Java code that treats a package as a security boundary. MITRE puts it plainly: Java packages are not inherently closed, so relying on them for code security is not good practice.
How it happens
Package scope, the default when you write no access modifier, exists to prevent accidental access by other parts of a program. MITRE calls it an ease of development feature, not a security feature.
// Vulnerable: package scope used as protection
class AccountStore {
String masterKey = loadKey(); // visible to the whole package
}
Once the package is distributed, other code can be placed in the same package name and reach the field.
What an attacker gains
MITRE lists two impacts. Any data in a Java package can be read from outside the Java framework if the package is distributed, and the data in a Java class can be modified by anyone outside the framework. The record has no observed CVEs.
How to find it
Static analysis can find some instances. A review habit also works: for every field holding a key, token or setting that matters, check that its modifier is private.
How to fix it
MITRE's guidance: data should be private static and final whenever possible. That protects your code by instantiating early, preventing access and tampering.
final class AccountStore {
private static final byte[] MASTER_KEY = loadKey();
}
Declare classes final where you can, and expose values through narrow methods that return what callers need, never the raw data.
Quick check
Is package scope the same as private?
No. Private limits access to the class. Package scope allows any class in the same package, and in a distributed library that includes code from others.
