So the salesforce security review of my mannaged package failed due to data in log lines they have stated the below:

Issue Description

Revealing information in debug statements can help reveal potential attack vectors to an attacker. Debug statements can be invaluable for diagnosing issues in the functionality of an application, but they should not publicly disclose sensitive or overly detailed information (this includes PII, passwords, keys, and stack traces as error messages, among other things).

Ok so passwords, keys (assuming this is a security key or api key) i understand can anyone tell be does PII include user id and or name of user preforming the action?

Can log statments include the Salesforce internal ids for records? or does this count as a key?

Im a bit supprised i cant include a stacktrace...

1 Answer 1


Record IDs are not keys. PII are things like names, email addresses, phone numbers, and so on. Technically a User ID isn't PII, nor are they keys. However, I feel like you're focused in the wrong direction. Regardless of the actual rules, I would state that debug statements should not be left in code for production.

If a tree falls in a forest, and nobody's around to observe it, does it still make a sound?

Debug statements actively harm application performance, even if logging isn't enabled for a given transaction. Apex isn't "smart" enough to automatically disable these statements at runtime, and so the parameters still have to be serialized using toString(), which wastes CPU time.

You should not allow any debug statements to go to production under any circumstances. Not only is it impossible to run afoul of this security review issue if you have no debug statements, your customers will be happier with an app that runs faster.

  • Related Question - I was thinking you could add a custom permission, and then wrap the debug statement in that, in case I needed it at some point to debug something. e.g if custompermission, {system.debug} I assumed the debug would only fire if the permission is assigned - is that correct though? Or if it is there, is it always going to be triggered, regardless of the if statement? Commented Feb 23 at 13:29
  • 1
    @BritishBoyinDC Debug statements only run when they're encountered, so using a custom permission as a guard would work, but then you'd also want to have a framework, so ultimately you'd only have one System.debug in your entire code base, in a utility class somewhere. Still, I've rarely ever seen an instance where debug statements have ever solved a production issue.
    – sfdcfox
    Commented Feb 23 at 13:47
  • 2
    I totally agree with this answer. I would, however, say that Salesforce's rationale for disallowing debug logs to include stack traces is misdirected in saying these "help reveal potential attack vectors to an attacker". Why? Because the attacker can only see such debug logs if they have subscriber access (otherwise debug from the package isn't visible). If they do have such access, they probably also have access to the vendor's infrastructure, e.g. git repo, and the org's data. Saying it's about performance is far more level headed.
    – Phil W
    Commented Feb 23 at 13:54
  • I've seen a few examples of folks doing logging using immediately published platform events. Do they fall foul of these performance issues? Would SR look more favorably on a solution that writes to an object somewhere so the customer can understand and control access better? Commented Feb 23 at 13:59
  • 1
    On the platform event-based logging, if the logged data persists on the org itself, this has a negative impact on storage and there can be security concerns as anyone with read permission can see the details. If it is sent off-platform, there may be security concerns still, depending what the content is.
    – Phil W
    Commented Feb 23 at 14:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .