Recently, at the organization I work for, we've been using a static code inspection tool.

One of the more interesting findings is that private information, such as passwords, may be stored in the heap where it could potentially be intercepted by an application scanning the heap or perhaps a disk swap.

The app being scanned is a web app that runs on a private web server behind a firewall, so I'm wondering if this finding is relevant.

The app is written in C# and the "remediation" suggestion is to store sensitive information in character arrays rather than string objects so that they aren't stored in the heap. I realize it would take up some time to properly remediate this issue, so I wanted to ask if this finding is relevant when the code runs on a private server because presumably, a hypothetical attacker would have to bypass the firewall and run malicious code on the web server to steal data.

  • I'm also questioning how storing a password in a character array is any safer. That password gets passed to some procedure, and most likely as a string... which gets allocated on the heap. Commented Nov 4, 2021 at 3:26
  • My understanding is that a character array gets stored in the function call stack rather than the heap. Commented Nov 4, 2021 at 4:16
  • 3
    My understanding is that heap, stack, or static memory are all vulnerable to scanning since the only difference between them is what some easily ignored pointer thinks. Commented Nov 4, 2021 at 10:19
  • 1
  • 1
    @BenCottrell This is a matter that upper management in the organization was sold this static code inspection tool and it falls on me to report back to them about the "findings" from this tool and how I "remediated" them. I can make changes to the code to "remediate" this "finding", or I can "suppress" it. I would like to be able to give them reasons for my decision. Commented Nov 4, 2021 at 14:00

1 Answer 1


In C# and Java, String objects are immutable, so they remain in memory until the GC decides to reuse that memory. A character array is mutable, so it can be overwritten with other (e.g. random or zero) data as soon as the credentials are no longer needed, reducing the time the data is potentially visible to attackers.

So the solution is not just dropping in a mutable type instead of an immutable string, but also requires actively overwriting it as soon as it is no longer needed. There are classes specifically designed for this purpose that make this easy, e.g. SecureString, but also note the disclaimers in the limitations section.

Whether that is relevant to your threat model depends on a lot of factors. For example, it is more relevant if

  • the difference between the time the credential data actually needs to be in memory (possibly only a few 100ms while assembling a request) between the uptime of your application (in the case of a web server, perhaps days or months) is large
  • the number of credentials that may be loaded into memory during the uptime of your application is greater than the number of credentials used concurrently.
  • your application is running in a context where the degree of isolation to other applications is not under your control

Of course, exploiting this vulnerability requires access to the memory, but note that this may be worse if you store coredump-files on crashes, or similar. If such a file leaks, you want it to contain the absolute minimum number of credentials possible. The likelyhood of that happening is up to your judgement... e.g. how likely is it for a server admin of your organisation to send the developer of the application a heap dump via unencrypted mail while debugging some problem?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.