Do not operate on unvalidated or untrusted data (also known as tainted data) in a doPrivileged() block. An attacker can supply malicious input that could result in privilege escalation attacks. Appropriate mitigations include hard coding values rather than accepting arguments (when appropriate), or validating (a.k.a. sanitizing) /sanitizing data before the privileged operations.
...
One potential drawback of this approach is that effective sanitization methods can be difficult to write. A benefit of this approach is that it works well in combination with taint analysis (see Automated Detection, below). For more information on how to securely validate and sanitize a file, see FIO04-J. Beware of symbolic links and other special files when selecting a file to open.
Compliant Solution (Built-in File Name and Path)
Sanitization of tainted inputs always carries the risk that the data is not fully sanitized. Both file and path name equivalence and directory traversal are common examples of vulnerabilities arising from the improper sanitization of path and file name inputs (see IDS21-J. Canonicalize path names before validating them). A design that requires an unprivileged user to access an arbitrary, protected file (or other resource) is always suspect. Consider alternatives such as using a hard code hardcodeed resource name or permitting the user to select only from a list of options that are indirectly mapped to the resource names.
This compliant solution both explicitly hard codes hardcodes the name of the file and also confines the variables used in the privileged block to the same method. This ensures that no malicious file can be loaded by exploiting the privileges of the corresponding code.
...