skip to content

Which settings entries look like plain configuration but actually carry authority inside the value itself?

level: middleimportance: should knowfreq 50%

answer

  1. the key name lied, the value did not
  2. look for a value inside a value
  3. what does the receiving system actually check
  4. connection strings, callback links, join values
  5. read-only is still a right

basics

~20 s

Compound values: a connection string with the account password inside it, a callback link whose query value is the whole permission, a join value that admits a new node, a header template holding a token. Classify the value, never the key name.

solid answer

~50 s

The entries that get missed are the ones whose key name describes a location or a shape while the value carries a credential. The recurring shapes are a connection string with the account password embedded, a callback or webhook link where the link *is* the permission because the receiving system checks nothing else, a cluster or agent join value that admits a new member, a header or command template with a token interpolated into it, and anything labelled read-only that still confers reads nobody granted. The spotting rule is mechanical: read the value, not the key, and ask the disclosure test of the value as a whole. A useful second pass is to look for any entry whose value contains a second value - a `@`, a query parameter, an embedded field - because a credential usually hides inside a compound.

code

pseudocode · 13 lines
pseudocode
# the value carries authority, whatever the key is called
reports_db_url = 'db://reporter:[email protected]/reports'  # password inside
score_callback = 'admin.internal/hooks/score?k=Z9d4ka'               # link IS permission
node_join      = 'join-7b1c40'                                       # admits a new node
auth_header    = 'Authorization: Bearer tok-9c14'                    # token in a template
readonly_key   = 'ro-4c19e2'                                         # read is still a right

# the value grants nothing on its own
reports_db_host = 'reports-db.internal'
score_queue     = 'score-requests'
page_size       = '50'

rule: classify(entry.value), never classify(entry.key_name)

go deeper

for a junior

Remember that the key name is not the classification. Open the value of every entry, including the ones called url or endpoint, and check whether a credential is sitting inside it.

for a middle

Name the recurring compound shapes and say why each one confers authority: the embedded account password, the link that is itself the permission, the join value, the filled-in header template.

for a senior

Handle the half-split case with judgment - which half grants what, what the reassembled value is, and where a split quietly re-forms into a single string someone treats as configuration.

for a principal

Set the default the organisation uses for a new compound entry and who reviews it, so the shapes are caught by convention instead of by whoever happens to read the value carefully.

## Why this class of entry survives a review A classification pass usually goes down the key names: `password` - secret; `token` - secret; `url`, `host`, `queue`, `size` - configuration. That pass is fast and it is how credentials end up in the configuration pile, because several perfectly ordinary settings entries carry authority **inside the value** while the key name describes a location or a shape. The disclosure test has no trouble with any of these. The problem is that nobody applies it, because the key name already answered the question. ## The recurring shapes - **A connection string.** `db://reporter:[email protected]/reports` is mostly a location, and one field of it opens the account. The entry is a secret; the hostname portion, alone, is not. - **A callback or webhook link whose value is the permission.** If the receiving system accepts a posted payload on the strength of the link alone, the link is a credential: whoever holds it can post as us. The key is called `url` and the value is a key. - **A join value.** One value that admits a new node, agent or worker into a group is a credential for the act of joining, and the thing it buys - membership - is usually worth more than one read. - **A header or command template.** `Authorization: Bearer tok-9c14` sitting in a request template is the token, with extra punctuation around it. - **Anything described as read-only.** Read is a right. An entry called `readonly_key` is a credential whose disclosure grants reads to someone who was never granted them. - **A pre-signed or time-boxed link.** A link that carries its own permission is a credential for as long as it is valid; validity bounds the cost and does not change the class. ## The spotting rule 1. **Classify the value, not the key name.** Read every value, even in entries whose name looks boring. 2. **Look for a value inside a value.** A `@` before a host, a query parameter, a colon-separated field, a template placeholder that has been filled in - credentials hide inside compounds far more often than they sit alone. 3. **Ask what the receiving system checks.** If the answer is 'this value, and nothing else', you are holding a credential regardless of what it looks like. The complement of the rule is just as useful: an entry whose name sounds alarming may grant nothing at all. `security_realm_name`, `encryption_algorithm`, `audit_endpoint` are settings. Alarm is not a classification. ## The half-split trap A common partial fix is to split a compound: keep the hostname and the database name as configuration and store only the password half as a secret. By the test that is correct - the remaining half grants nothing on its own. Two practical cautions come with it. The halves drift apart, so the reassembled value tends to reappear somewhere convenient as a single string. And the moment of reassembly is where a full connection string, credential included, becomes a value the process is holding and could write down. Classify each half honestly, and treat the assembled value as the secret it is. ## What the interviewer is checking This is a question about whether a candidate applies the test mechanically or pattern-matches key names. The strongest answers name at least two of the compound shapes, state the rule as 'classify the value', and add the inverse case: an entry whose name sounds sensitive but which confers nothing. A candidate who only lists `password` and `api_key` has described the entries that were never going to be missed.

  • A team splits the connection string so only the password half is stored as a secret. Is the rest safe to publish?
    By the test, yes - a hostname and a database name grant nothing on their own. Two cautions travel with the split: the halves drift apart and someone re-joins them into a single convenient string, and the assembled value is a full credential at the moment of use. Classify each half honestly and treat the assembled string as the secret.
  • A callback link is the only thing the receiving system checks. What class is it?
    A secret. Possession of the link is the whole authorisation, so it belongs with the credentials and is replaced like one. The practical difficulty is that links are handled as though they were harmless, which is precisely the cost of the entry having been filed as configuration in the first place.

saying these in an interview costs you the question

  • If the key name does not say password or key, it is configuration
  • A URL is not a secret; links are addresses by nature
  • A connection string is configuration because it is mostly a hostname
  • A join value is harmless - it only lets a node join
  • An entry named security or audit must be a secret