In Ruby 4.0, can calling to_sym on untrusted input such as a delivery status parameter leak memory, and how would you guard against it?

## Why this used to be a classic vulnerability Symbols are interned: Ruby keeps one object per name in a global **symbol table**. For many years that table only grew. Any code that turned request data into symbols - a status parameter passed to `to_sym`, keys symbolized from a parsed payload, a header name interned for lookup - let a client create an unbounded number of permanent objects by sending unique values. Memory climbed until the process died. **Ruby 2.2** changed this: most symbols returned by `String#to_sym` and `String#intern` became garbage-collectable. ## Static and dynamic symbols | Kind | Created by | Collected? | |---|---|---| | **static** | symbol literals in source (`:delivered`), names the interpreter registers for methods, constants and variables | never - they live as long as the process | | **dynamic** | `String#to_sym`, `String#intern`, interpolated literals such as `:"status_#{code}"` | yes, when nothing references them | | **pinned dynamic** | a dynamic symbol that Ruby later needs as an internal identifier | no - it is made permanent | `String#to_sym` first looks the name up; if a static symbol with that name exists it simply returns it, so converting `"delivered"` never creates anything new. Only unseen names produce dynamic symbols. ## When a dynamic symbol becomes permanent CRuby turns a dynamic symbol into a permanent entry when it has to assign it an internal ID - the identifier the VM uses for method tables and variable names. Defining a method with that name is the clearest case: ```ruby name = "track_#{input}".to_sym Parcel.define_method(name) { status } # the name is now permanent ``` So the memory question and the metaprogramming question meet: code that turns user input into **method names** keeps those names forever, and has worse problems than memory. Any attacker-chosen name that becomes a method, attribute or constant is a design defect in its own right. ## Symbols kept alive by your own code Collectable does not mean collected. A dynamic symbol lives as long as something references it: - a class-level registry or memoized lookup that stores every status ever seen; - a long-lived cache keyed by symbols derived from input; - log or metrics buffers that accumulate symbol values. These are ordinary leaks - the same as storing unique strings - but they are easy to miss because symbols look like constants. ## Guarding a delivery-status parameter The robust approach avoids creating symbols from input at all: 1. Declare the allowed values once: `STATUSES = %i[pending in_transit out_for_delivery delivered returned].freeze`. 2. Match the incoming text against their names with `STATUSES.find { |s| s.name == input }`. `Symbol#name` returns a cached frozen string, so the comparison allocates nothing and unknown input yields `nil`. 3. Reject or report `nil` at the boundary instead of passing the raw value deeper. 4. Keep calls such as `to_sym` for text that has already passed that check, or for data your own code produced. ## Checking for growth `Symbol.all_symbols` returns an array of every symbol currently in the table, so `Symbol.all_symbols.size` before and after a suspicious workload (with a `GC.start` in between) shows whether symbols are accumulating. On Ruby 2.2 and later, a loop that creates 100,000 throwaway symbols with `to_sym` and drops them returns to roughly its starting count after a GC, while the same number of names passed to `define_method` stays. ## What a senior answer includes - The history: pre-2.2 symbol tables only grew, which is why "never `to_sym` user input" became folklore. - The current rule: dynamic symbols are collectable; static and pinned ones are not. - The residual risks: pinning through metaprogramming, and your own long-lived references. - The fix that does not depend on GC details: an allowlist, compared by `name`.