<p>Many programming languages (such as Java) make strings immutable to mitigate many potential serious security threats.</p>
<p>Are there any major downsides or issues with a language having all strings immutable?</p>

<immutable><strings>
What are the downsides of making all strings immutable to improve security and concurrency?
CC BY-SA 4.0
2023-05-16T17:56:36.630Z
Is there a source on immutable strings mitigating security threats? Anyone with access to code can probably access memory addresses directly and modify the string.
kouta-kun
CC BY-SA 4.0
2023-05-16T17:57:49.760Z
I really wouldn't know what kind of security immutable strings could protect against
mousetail 'he-him'
<h1>C FFI</h1>
<p>The only &quot;definite&quot; downside I can think of is C-FFI. If you want to have C-interop, you may need to convert your language into C-style string (which is mutable) back and forth every time, or you try to use strings as char arrays in your language directly to avoid the conversion, which mostly defeats the purpose of having a dedicate string type.</p>

CC BY-SA 4.0
2023-05-16T17:52:50.210Z
2023-05-16T17:56:54.590Z
2023-05-16T17:56:54.590Z
ice1000
CC BY-SA 4.0
2023-05-16T17:55:13.630Z
I don't think this is related to C FFI in and of itself, since the question doesn't mention whether they would be null-terminated strings or length-prefixed.
kouta-kun
CC BY-SA 4.0
2023-05-16T17:56:42.283Z
@kouta-kun I'm talking about immutable vs. mutable strings.
ice1000
<p>If I'm not mistaken, the upside for the choice in favor of immutable strings is that it saves memory. Instead of having many duplicates, the same copy can be referenced, as long as it's guaranteed that the reference target does not change (and instead, to &quot;change&quot; a string variable, the reference is changed, potentially to another existing immutable string or one that gets newly created, with the garbage collection cleaning up the ones that are no longer in use). Also saves performance by avoiding string copying, memory (re-)allocation, all of that. With the downside that frequent string manipulation should not be done with the <code>String</code> class (that just represents a single static string), but with flexible-memory non-immutable <code>StringBuilder</code> and only pull the final string out after being done with the manipulations.</p>
<p>I don't see how there's significant security benefits (as if this is to counter off-by-one or format-string vulnerabilities as in C, but C++ has dynamic-size strings and these are just fine, at some size cost but Java's comes at a size cost too). Maybe indirectly for concurrency, in terms of at least this datatype not changing during concurrent use? But does not help with all the other types/objects, right?</p>

CC BY-SA 4.0
2024-06-12T22:22:00.310Z
2024-06-12T22:22:00.310Z
skreutzer
<h2>Security is better for mutable strings in some situations</h2>
<p>When memory is freed it is not cleared. The string may stay in memory for a long time after you are done using it potentially exposing sensitive information to other processes that can snoop on your memory.</p>
<p>For that reason, some languages have the concept of a <code>SecureString</code> that is mutable so you can zero out the data when you are done using it to prevent other processes from reading it.</p>

CC BY-SA 4.0
2023-05-16T17:54:22.933Z
2023-05-16T17:54:22.933Z
mousetail 'he-him'
CC BY-SA 4.0
2023-05-16T17:56:58.737Z
In Java, char arrays are preferred over strings for passwords for this very reason, even though Java’s strings are immutable.
Seggan
<h1>Performance</h1>
<p>Immutability in general is bad for performance. If you concatenate many strings together in a loop, for example, the needless copying and the GC overhead (if any) <em>will</em> hurt performance. For this reason, many languages have a mutable string type, for example Java’s <a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StringBuilder.html" rel="noreferrer"><code>StringBuilder</code></a>.</p>

CC BY-SA 4.0
2023-05-16T17:56:19.103Z
2023-05-16T18:52:12.043Z
2023-05-16T18:52:12.043Z
Seggan
CC BY-SA 4.0
2023-06-29T06:32:48.240Z
Some of this can be mitigated by being more clever about implementing string operations, for example using *Ropes*. The Truffle framework has a very clever string implementation inspired by Ropes: https://github.com/oracle/graal/blob/master/truffle/docs/TruffleStrings.md
Jörg W Mittag
# What are the downsides of making all strings immutable to improve security and concurrency?
Posted by: username_0 on 2023-05-16
Many programming languages (such as Java) make strings immutable to mitigate many potential serious security threats.

Are there any major downsides or issues with a language having all strings immutable?
**Tags:** immutable strings
> **Comments:**
> **username_1**: Is there a source on immutable strings mitigating security threats? Anyone with access to code can probably access memory addresses directly and modify the string.  
> **username_2**: I really wouldn't know what kind of security immutable strings could protect against  
---
## 4 answers
### Answer by username_5 on 2023-05-16. Score: 15
# Performance

Immutability in general is bad for performance. If you concatenate many strings together in a loop, for example, the needless copying and the GC overhead (if any) *will* hurt performance. For this reason, many languages have a mutable string type, for example Java’s [`StringBuilder`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StringBuilder.html).
> **Comments:**
> **username_6** (2023-06-29): Some of this can be mitigated by being more clever about implementing string operations, for example using *Ropes*. The Truffle framework has a very clever string implementation inspired by Ropes: https://github.com/oracle/graal/blob/master/truffle/docs/TruffleStrings.md  
---
### Answer by username_2 on 2023-05-16. Score: 10
## Security is better for mutable strings in some situations

When memory is freed it is not cleared. The string may stay in memory for a long time after you are done using it potentially exposing sensitive information to other processes that can snoop on your memory.

For that reason, some languages have the concept of a `SecureString` that is mutable so you can zero out the data when you are done using it to prevent other processes from reading it.
> **Comments:**
> **username_5** (2023-05-16): In Java, char arrays are preferred over strings for passwords for this very reason, even though Java’s strings are immutable.  
---
### Answer by username_3 on 2023-05-16. Score: 2
# C FFI

The only "definite" downside I can think of is C-FFI. If you want to have C-interop, you may need to convert your language into C-style string (which is mutable) back and forth every time, or you try to use strings as char arrays in your language directly to avoid the conversion, which mostly defeats the purpose of having a dedicate string type.
> **Comments:**
> **username_1** (2023-05-16): I don't think this is related to C FFI in and of itself, since the question doesn't mention whether they would be null-terminated strings or length-prefixed.  
> **username_3** (2023-05-16): @kouta-kun I'm talking about immutable vs. mutable strings.  
---
### Answer by username_4 on 2024-06-12. Score: 0
If I'm not mistaken, the upside for the choice in favor of immutable strings is that it saves memory. Instead of having many duplicates, the same copy can be referenced, as long as it's guaranteed that the reference target does not change (and instead, to "change" a string variable, the reference is changed, potentially to another existing immutable string or one that gets newly created, with the garbage collection cleaning up the ones that are no longer in use). Also saves performance by avoiding string copying, memory (re-)allocation, all of that. With the downside that frequent string manipulation should not be done with the `String` class (that just represents a single static string), but with flexible-memory non-immutable `StringBuilder` and only pull the final string out after being done with the manipulations.

I don't see how there's significant security benefits (as if this is to counter off-by-one or format-string vulnerabilities as in C, but C++ has dynamic-size strings and these are just fine, at some size cost but Java's comes at a size cost too). Maybe indirectly for concurrency, in terms of at least this datatype not changing during concurrent use? But does not help with all the other types/objects, right?
---
