GitHub Security Guide

1. Client-Side Secret Exposure

Framework-specific traps that ship your secrets to every browser

Modern frontend frameworks have a concept of build-time environment variables — values that get embedded directly into your compiled JavaScript bundle and sent to every user's browser. This is by design for things like your public analytics ID. It is catastrophic for API keys, database URLs, or any secret.

AI-generated code frequently gets this wrong because it doesn't distinguish between server-side and client-side execution contexts.

Framework Danger Zones

# .env
NEXT_PUBLIC_STRIPE_KEY=sk_live_...   ← WRONG: bundled into client JS
NEXT_PUBLIC_OPENAI_KEY=sk-proj-...  ← WRONG: visible in DevTools

# Correct — no NEXT_PUBLIC_ prefix = server only
STRIPE_SECRET_KEY=sk_live_...
OPENAI_API_KEY=sk-proj-...

# .env
VITE_API_SECRET=abc123...    ← WRONG: bundled into client
VITE_DB_PASSWORD=hunter2     ← WRONG: visible in page source

# Private vars in Vite must NOT have the VITE_ prefix
# and must only be read in server-side code

# Everything prefixed REACT_APP_ is public
REACT_APP_FIREBASE_API_KEY=...   ← in the bundle
REACT_APP_TWILIO_AUTH_TOKEN=...  ← in the bundle

The Correct Pattern: Proxy Through Your Server

The fix is always the same regardless of framework: the browser should never call a third-party API directly with a secret. Route the call through your own API endpoint, which holds the secret server-side.

// React component
const res = await fetch(
  "https://api.openai.com/v1/chat",
  {
    headers: {
      Authorization: `Bearer ${
        process.env.REACT_APP_OPENAI_KEY
      }`  // ← in the bundle
    }
  }
);

// React component — calls YOUR api
const res = await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ prompt })
});

// /api/chat (server-side)
// process.env.OPENAI_API_KEY lives here
// never touches the browser

Auditing Your Built Bundle

Attackers extract secrets from production bundles using simple string analysis. You can do the same to audit your own build before shipping:

# Build your app first, then search the output
npm run build

# Search for common secret patterns in the bundle
grep -r "sk-" ./dist
grep -r "sk_live" ./dist
grep -r "AKIA" ./dist          # AWS key prefix
grep -r "Bearer " ./dist
grep -r "password" ./dist

# Or use trufflehog on your built output
trufflehog filesystem ./dist

2. Git History — Secrets Are Never Truly Deleted

Deleting a file does not remove it from history

This is one of the most misunderstood aspects of git. When you commit a secret and then delete it in the next commit, the secret is still fully accessible in git history. Anyone with access to the repo — or anyone who cloned it before the deletion — can retrieve it with a single command.

# Find all commits that touched .env or config files
git log --all --full-history -- "**/.env"
git log --all --full-history -- "**/config.js"

# View the content of a specific past commit
git show <commit-hash>:.env

# Search entire history for a string pattern
git log -p | grep -i "api_key|secret|password|token"

If a Secret Was Committed — Immediate Response

# Step 1: Rotate the secret IMMEDIATELY (assume it's already compromised)
# Do this before anything else — history rewriting takes time

# Step 2: Remove secret from history using git-filter-repo
pip install git-filter-repo
git filter-repo --path .env --invert-paths

# Or remove a specific string from all history
git filter-repo --replace-text <(echo 'sk-proj-abc123==>REMOVED')

# Step 3: Force push all branches (coordinate with team first)
git push origin --force --all

# Step 4: Invalidate all existing clones
# Anyone who cloned before must re-clone — old clones still have the history

Prevention: .gitignore Before First Commit

# Create .gitignore BEFORE git init or first commit
# Minimum entries for any project:

.env
.env.local
.env.*.local
.env.production
*.pem
*.key
secrets/
credentials.json
service-account.json

3. Repo Misconfiguration

Default GitHub settings are not secure defaults

Branch Protection Rules

Without branch protection on main, any contributor — or an attacker with a compromised token — can push directly, bypass CI, and deploy malicious code.

Repo Visibility

Making a repo public is irreversible in terms of data exposure — if a secret was in the repo before it was made public, bots may have already scraped it. Additionally, even "private" repos at the free tier can become public accidentally or through permission misconfiguration.

4. GitHub Actions Security

CI pipelines are a common lateral movement path

The Fork PR Attack

By default, workflows triggered by pull_request from forks do not have access to secrets. But pull_request_target runs in the context of the base repo and does — meaning a malicious fork PR can exfiltrate all your CI secrets if your workflow is misconfigured.

on:
  pull_request_target:  # ← has secrets
    types: [opened]

jobs:
  build:
    steps:
      - uses: actions/checkout@v4
        with:
          # Checking out fork code with
          # access to secrets = RCE risk
          ref: ${{ github.event.pull_request.head.sha }}

on:
  pull_request:  # ← no secrets for forks
    types: [opened, synchronize]

# For deploy workflows that need secrets,
# use workflow_run triggered after
# pull_request completes — never give
# fork code direct access to secrets

GITHUB_TOKEN Least Privilege

The GITHUB_TOKEN available in every workflow defaults to broad write permissions in many repos. Scope it to the minimum your workflow actually needs.

# Set default permissions to read-only for the whole workflow
permissions: read-all

jobs:
  deploy:
    permissions:
      contents: read        # only what's needed
      id-token: write       # for OIDC auth if required
      # everything else: none (not declared = denied)

Pin Third-Party Actions to a Commit SHA

uses: actions/checkout@v4 means "whatever the v4 tag points to today." Tag references can be moved by the action maintainer (or an attacker who compromises their account) to point to malicious code. Pin to a specific commit SHA instead.

- uses: actions/checkout@v4
- uses: actions/setup-node@v4

- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
- uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af  # v4.1.0

5. PAT Hygiene — Fine-Grained, Scoped, Expiring

A single overprivileged token can hand an attacker your entire org

Personal Access Tokens (PATs) are a major risk surface because developers tend to create them once, give them broad permissions "just in case," set no expiry, and then use them across multiple systems. When one of those systems is compromised, the attacker has a token with access to everything.

PAT Permission Reference

6. Third-Party Integrations — Audit & Revoke

Every integration is a potential breach vector

GitHub integrations — OAuth apps, GitHub Apps, and CI/CD connections — accumulate over time. Each one represents a third party that has been granted some level of access to your repos or org. When that third party is compromised (it happens regularly), the attacker inherits whatever permissions you granted them.

Common Overprovisioning Patterns

How to Audit Your Integrations

Personal integrations:
  Settings → Applications → Authorized OAuth Apps
  Settings → Applications → Authorized GitHub Apps
  Settings → Developer settings → Personal access tokens

Organization integrations:
  Org Settings → Third-party access
  Org Settings → GitHub Apps
  Org Settings → OAuth application policy

For each integration, ask:
  1. Do we still use this?
  2. What permissions did we grant?
  3. Is this the minimum needed?
  4. When was it last active?

GitHub Security Checklist

Work through this list for every active repository and organization.

Related Tools & Resources