Skip to content
skillsafebeta
← Report library
Purpose / Development

Golang Samber Slog Skill Security Audit

What the author says it does (original text)

Structured logging extensions for Golang using samber/slog-**** packages — multi-handler pipelines (slog-multi), log sampling (slog-sampling), attribute formatting (slog-formatter), HTTP middleware (slog-fiber, slog-gin, slog-chi, slog-echo), and backend routing (slog-datadog, slog-sentry, slog-loki, slog-syslog, slog-logstash, slog-graylog...). Apply when using or adopting slog, or when the codeb

Independent security check

Do not install or run it yet

Files checked
6
Risks found
4
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 2
High risk

Request-body logging can send passwords, tokens, and personal data to external log systems

Source references: 4
What we found

The main example explicitly enables `WithRequestBody: true`, while the configuration reference only states that bodies are size-capped. The documented hiding mechanism covers headers and does not establish that arbitrary sensitive body fields are scrubbed. The Skill also recommends routing logs to several cloud and notification backends.

Why this matters

If API requests contain login credentials, access tokens, payment information, health data, or other personal information, those values may enter Loki, Sentry, Datadog, Slack, or a webhook and become subject to those systems' retention, access, and cross-border transfer policies.

The example actively enables request-body logging. The reference only documents a size cap, while the stated hiding controls cover headers, not arbitrary body fields. If a body contains passwords, tokens, or personal data and logs use Loki, Datadog, Sentry, or another sink, that data could leave the process. Users can require body logging to remain off by default, ask for documented body-level redaction, and restrict approved sinks.

SKILL.md:168In the instructionsOpen original file
```go// Gin with filters — skip health checksrouter.Use(sloggin.NewWithConfig(logger, sloggin.Config{    DefaultLevel:     slog.LevelInfo,    ClientErrorLevel: slog.LevelWarn,    ServerErrorLevel: slog.LevelError,    WithRequestBody:  true,    Filters: []sloggin.Filter{        sloggin.IgnorePath("/health", "/metrics"),    },}))```
Show 3 other places
references/http-middlewares.md:28In the instructionsOpen original file
| `WithRequestID` | `bool` | `false` | Include request ID || `WithRequestBody` | `bool` | `false` | Include request body (capped) || `WithResponseBody` | `bool` | `false` | Include response body (capped) || `WithRequestHeader` | `bool` | `false` | Include request headers || `WithResponseHeader` | `bool` | `false` | Include response headers || `WithSpanID` | `bool` | `false` | Include OpenTelemetry span ID |
references/http-middlewares.md:37In the instructionsOpen original file
**Global configuration variables** (set before creating middleware):- `RequestBodyMaxSize` / `ResponseBodyMaxSize` — default 64KB each- `HiddenRequestHeaders` / `HiddenResponseHeaders` — headers to redact- `TraceIDKey` / `SpanIDKey` — context key names for OpenTelemetry
SKILL.md:187In the instructionsOpen original file
| Category     | Packages                                                   || ------------ | ---------------------------------------------------------- || Cloud        | `slog-datadog`, `slog-sentry`, `slog-loki`, `slog-graylog` || Messaging    | `slog-kafka`, `slog-fluentd`, `slog-logstash`, `slog-nats` || Notification | `slog-slack`, `slog-telegram`, `slog-webhook`              || Storage      | `slog-parquet`                                             || Bridges      | `slog-zap`, `slog-zerolog`, `slog-logrus`                  |
Medium risk

Credential examples encourage placing real bot tokens and webhook URLs directly in Go source

Source references: 5
What we found

The Slack, Telegram, and webhook examples place credentials or authorization-bearing URLs in string fields. The supplied values are placeholders, not exposed real secrets, but a user may copy the examples and substitute live values directly.

Why this matters

Live credentials may enter Git history, code review systems, build logs, or shipped artifacts. Anyone obtaining them could impersonate a bot, access data within its granted scope, or inject messages into alert channels.

These are code examples containing placeholders, not exposed live credentials. However, they represent webhook URLs and bot tokens as inline Go strings and do not show loading them from environment variables or a secret manager nearby. A user who substitutes real values and commits the source could expose credentials through version history or other readers. Users can ask for secure-loading examples and restrict secrets from logs, commits, and build artifacts.

references/backend-handlers.md:168In the instructionsOpen original file
// Via webhookhandler := slogslack.Option{    Level:      slog.LevelError,    WebhookURL: "https://hooks.slack.com/services/...",    Channel:    "alerts",}.NewSlackHandler()// Via bot tokenhandler := slogslack.Option{    Level:    slog.LevelError,    BotToken: "xoxb-...",    Channel:  "alerts",}.NewSlackHandler()```
Show 4 other places
references/backend-handlers.md:188In the instructionsOpen original file
handler := slogtelegram.Option{    Level:    slog.LevelError,    Token:    "your-bot-token",    Username: "@your-channel",}.NewTelegramHandler()```
references/backend-handlers.md:200In the instructionsOpen original file
handler := slogwebhook.Option{    Level:    slog.LevelError,    Endpoint: "https://webhook.site/your-id",    Timeout:  10 * time.Second,}.NewWebhookHandler()```
references/backend-handlers.md:185In the instructionsOpen original file
```goimport slogtelegram "github.com/samber/slog-telegram/v2"handler := slogtelegram.Option{    Level:    slog.LevelError,    Token:    "your-bot-token",    Username: "@your-channel",}.NewTelegramHandler()```
references/backend-handlers.md:197In the instructionsOpen original file
```goimport slogwebhook "github.com/samber/slog-webhook/v2"handler := slogwebhook.Option{    Level:    slog.LevelError,    Endpoint: "https://webhook.site/your-id",    Timeout:  10 * time.Second,}.NewWebhookHandler()```
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 2
Medium risk

Replacing Fanout with Pool sends each record to only one backend and can weaken audit and alert coverage

Source references: 4
What we found

The Skill correctly states that `Pool` sends each record to one handler, but its common-mistakes table recommends Pool for multiple synchronous handlers. If audit, alerting, or forensic records that require broadcast are moved from `Fanout` to `Pool`, each backend receives only a distributed subset.

Why this matters

Sentry may miss some errors, an archive may lack audit events, and backends can no longer be cross-checked against a complete record set. This weakens incident detection and investigation.

The source correctly says Pool sends each record to only one handler, but also presents it as the short fix for latency from multiple synchronous handlers. If a user applies that advice where every audit or alerting backend needs a complete copy, each backend receives only a subset, creating monitoring or forensic gaps. Users should require a clear distinction between load balancing and concurrent broadcast, and use Pool only for equivalent sinks where sharding is authorized.

SKILL.md:97In the instructionsOpen original file
| --- | --- | --- || `Fanout(handlers...)` | Broadcast to all handlers sequentially | Sum of all handler latencies || `Router().Add(h, predicate).Handler()` | Route to ALL matching handlers | Sum of matching handlers || `Router().Add(...).FirstMatch().Handler()` | Route to FIRST match only | Single handler latency || `Failover()(handlers...)` | Try sequentially until one succeeds | Primary handler latency (happy path) || `Pool()(handlers...)` | Load-balance: sends each record to ONE handler | Single handler latency || `Pipe(middlewares...).Handler(sink)` | Middleware chain before sink | Middleware overhead + sink |
Show 3 other places
SKILL.md:201In the instructionsOpen original file
| Mistake | Why it fails | Fix || --- | --- | --- || Sampling after formatting | Wastes CPU formatting records that get dropped | Place sampling as outermost handler || Fanout to many synchronous handlers | Blocks caller — latency is sum of all handlers | Use `Pool()` for concurrent dispatch || Missing shutdown flush on batch handlers | Buffered logs lost on shutdown | `defer handler.Stop(ctx)` (Datadog), `defer lokiClient.Stop()` (Loki), `defer writer.Close()` (Kafka) || Router without default/catch-all handler | Unmatched records silently dropped | Add a handler with no predicate as catch-all |
references/pipeline-patterns.md:123In the instructionsOpen original file
## Pool — Load-Balanced DispatchRandomly distributes each record to one handler from the pool. Useful when you have equivalent handlers and want to spread load.```gologger := slog.New(    slogmulti.Pool()(        lokiHandler1, // shard 1        lokiHandler2, // shard 2        lokiHandler3, // shard 3    ),)```**When to use:** Multiple equivalent sinks where you want throughput distribution. Latency = single handler latency (not sum like Fanout).
SKILL.md:95In the instructionsOpen original file
| Pattern | Behavior | Latency impact || --- | --- | --- || `Fanout(handlers...)` | Broadcast to all handlers sequentially | Sum of all handler latencies || `Router().Add(h, predicate).Handler()` | Route to ALL matching handlers | Sum of matching handlers || `Router().Add(...).FirstMatch().Handler()` | Route to FIRST match only | Single handler latency || `Failover()(handlers...)` | Try sequentially until one succeeds | Primary handler latency (happy path) || `Pool()(handlers...)` | Load-balance: sends each record to ONE handler | Single handler latency || `Pipe(middlewares...).Handler(sink)` | Middleware chain before sink | Middleware overhead + sink |
Medium risk

Declared access exceeds what reading logging guidance requires, including file writes, unrestricted Git, network, and agents

Source references: 3
What we found

The metadata requests Read, Edit, Write, wildcard Git commands, WebFetch, and Agent access together. The Skill body is logging-architecture guidance, so not all of these powers are necessary; in particular, `Bash(git:*)` is not restricted to read-only Git operations.

Why this matters

If the host treats this field as effective authorization, an error or contaminated later instruction during Skill use could modify project files, rewrite or publish Git state, access external content, or delegate work to additional agents, increasing the affected scope. The supplied evidence does not show that these powers were exercised.

`allowed-tools` is the Skill's active permission declaration and includes file editing/writing, every `git:*` subcommand, network fetching, and agent launch. Reading, Go tooling, and limited edits can fit adopting a logging library, and the text mentions external documentation lookup; the evidence does not show that unrestricted Git or Agent access is necessary for each use. If the host enforces this declaration, a prompt-influenced Skill could alter files, run destructive Git operations, or transmit content. Users can require least privilege, read-only Git, and per-use approval for network or agents.

SKILL.md:50In the instructionsOpen original file
      slog-mock: "0.1.0"allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs AskUserQuestion Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__*paths:
Show 2 other places
SKILL.md:2In the instructionsOpen original file
---name: golang-samber-slogdescription: "Structured logging extensions for Golang using samber/slog-**** packages — multi-handler pipelines (slog-multi), log sampling (slog-sampling), attribute formatting (slog-formatter), HTTP middleware (slog-fiber, slog-gin, slog-chi, slog-echo), and backend routing (slog-datadog, slog-sentry, slog-loki, slog-syslog, slog-logstash, slog-graylog...). Apply when using or adopting slog, or when the codebase already imports any github.com/samber/slog-* package."user-invocable: true
SKILL.md:67In the instructionsOpen original file
This skill is not exhaustive — refer to library documentation and code examples for more information:- For Go package docs, symbols, versions, importers, and known vulnerabilities, → See `samber/cc-skills-golang@golang-pkg-go-dev` skill (`godig`), preferred over Context7 for Go package facts.- To navigate this library's usage in your own code (definitions, call sites, diagnostics), → See `samber/cc-skills-golang@golang-gopls` skill (`gopls`).- Context7 remains a fallback for docs not indexed on pkg.go.dev.
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

This Skill is an instructional guide for Go structured logging, with examples for pipelines, sampling, formatting, HTTP middleware, and backend handlers. The supplied material contains no installation script, and its installation list is empty.

View source
SKILL.md:16In the instructionsOpen original file
        - go    install: []    skill-library-version:
SKILL.md:57In the instructionsOpen original file
# samber/slog-\*\*\*\* — Structured Logging Pipeline for Go20+ composable `slog.Handler` packages for Go 1.21+. Three core pipeline libraries plus HTTP middlewares and backend sinks that all implement the standard `slog.Handler` interface.

The Skill explicitly designs log delivery to external systems such as Sentry, Loki, Datadog, Slack, and webhooks. When these examples are adopted, log records leave the application process and may leave infrastructure controlled by the user.

View source
SKILL.md:187In the instructionsOpen original file
| Category     | Packages                                                   || ------------ | ---------------------------------------------------------- || Cloud        | `slog-datadog`, `slog-sentry`, `slog-loki`, `slog-graylog` || Messaging    | `slog-kafka`, `slog-fluentd`, `slog-logstash`, `slog-nats` || Notification | `slog-slack`, `slog-telegram`, `slog-webhook`              || Storage      | `slog-parquet`                                             || Bridges      | `slog-zap`, `slog-zerolog`, `slog-logrus`                  |

The Skill describes two useful safeguards: format or mask PII before routing records to backends, and flush buffered handlers during shutdown. These safeguards only apply when the generated code actually adopts and correctly configures them.

View source
SKILL.md:146In the instructionsOpen original file
Apply as a `Pipe` middleware so all downstream handlers receive clean attributes.```gologger := slog.New(    slogmulti.Pipe(slogformatter.NewFormatterMiddleware(        slogformatter.PIIFormatter("user"),          // mask PII fields        slogformatter.ErrorFormatter("error"),       // structured error info        slogformatter.IPAddressFormatter("client"),  // mask IP addresses    )).Handler(slog.NewJSONHandler(os.Stdout, nil)),)
SKILL.md:195In the instructionsOpen original file
**Batch handlers require graceful shutdown** — `slog-datadog`, `slog-loki`, `slog-kafka`, and `slog-parquet` buffer records internally. Flush on shutdown (e.g., `handler.Stop(ctx)` for Datadog, `lokiClient.Stop()` for Loki, `writer.Close()` for Kafka) or buffered logs are lost.
Start here · InstructionsSKILL.md
golang-samber-slog
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 3 more sections are available in the original file.

File reference map

References: 4
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records6 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • references/backend-handlers.mdFull text included
  • references/http-middlewares.mdFull text included
  • references/pipeline-patterns.mdFull text included
  • references/sampling-strategies.mdFull text included
  • evals/evals.jsonFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • evals/evals.jsonSupporting file
  • references/backend-handlers.mdSupporting file
  • references/http-middlewares.mdSupporting file
  • references/pipeline-patterns.mdSupporting file
  • references/sampling-strategies.mdSupporting file

Operations mentioned in code and instructions

Connect to websites
SKILL.md:12In the instructionsOpen original file
    emoji: "🪵"    homepage: https://github.com/samber/cc-skills-golang    requires:
SKILL.md:63In the instructionsOpen original file
- [github.com/samber/slog-multi](https://github.com/samber/slog-multi) — handler composition- [github.com/samber/slog-sampling](https://github.com/samber/slog-sampling) — throughput control
SKILL.md:64In the instructionsOpen original file
- [github.com/samber/slog-multi](https://github.com/samber/slog-multi) — handler composition- [github.com/samber/slog-sampling](https://github.com/samber/slog-sampling) — throughput control- [github.com/samber/slog-formatter](https://github.com/samber/slog-formatter) — attribute transformation
Run commands
SKILL.md:50In the instructionsOpen original file
      slog-mock: "0.1.0"allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs AskUserQuestion Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__*paths:
Lines read
1,341
File checksum (to compare versions)
87cddace5b6f706d3f01dc1b8027fb335dbd2602b866a233b94c65f181e16a3d