Skip to content

Rule Reference

SEC321lintai-ai-securitythreat-reviewsecuritystableserver_jsonwarn

server.json remotes: literal auth header

server.json remotes header commits literal authentication material

Public lane
threat-review
Category
security
Provider
lintai-ai-security
Scope
per-file
Surface
server_json
Tier
stable
Severity
warn
Confidence
high
Detection
structural
Remediation
message only
How to read this lane

Explicit malicious, secret-bearing, or spyware-like review.

How to read this category

Strong exploit, secret, or unsafe-execution signal.

Activation Model

Preset Activation

These presets explain where this rule appears in the product experience.

Lifecycle

Stable Lifecycle Contract

State

stable

Graduation rationale

Checks remotes[].headers[] auth-like values for literal bearer/basic material or literal API key style values.

Deterministic signal basis

ServerJsonSignals inspects remotes[].headers[] auth-like names and value literals without looking at packages[].transport.

Malicious corpus
server-json-literal-auth-header
Benign corpus
server-json-auth-header-placeholder-safe
structured evidence required remediation reviewed
Canonical note

Structural stable rule positioned as an explicit threat-review control: high-signal malicious, credential-bearing, or spyware-like behavior that stays opt-in rather than shaping the quiet default.

Nearby Signals

Related Rules

Why It Matters

Literal auth material inside server.json remote headers turns the registry artifact into a secret-bearing manifest. That is both a security problem and a portability problem for downstream consumers.

What Triggers

SEC321 applies to server.json remotes[].headers[] and triggers when an auth-like header carries literal bearer, basic, or API-key style material instead of a placeholder-backed variable.

Example that triggers:

json
{
  "headers": [
    {
      "name": "Authorization",
      "value": "Bearer sk_live_12345"
    }
  ]
}

Example that stays clean:

json
{
  "headers": [
    {
      "name": "Authorization",
      "value": "Bearer {TOKEN}",
      "variables": {
        "TOKEN": { "description": "API token", "isSecret": true }
      }
    }
  ]
}

False Positives

The rule is limited to auth-like header names and literal values. Dynamic placeholders stay clean, so this is not a blanket rule against authenticated remotes.

This rule now lives in threat-review because a committed literal auth header is a strong credential-bearing signal, and that kind of finding is better kept in an explicit opt-in review lane than in the softer preview MCP/config story.

Remediation

Replace the literal auth header value with a placeholder-backed variable declared on the same header object.