​

Secure Coding Practices

​

1. Input Validation

• Form fields
• URL parameters
• HTTP headers
• Cookies
• File uploads
• API payloads
• Webhook events
• CSV imports
• AI tool outputs
• Messages from queues or workers

​

Validation Strategies

​

2. Output Encoding

​

3. Parameterized Queries

# Vulnerable: user input changes query syntax
query = f"SELECT * FROM users WHERE email = '{email}'"

# Safer: user input is passed as data
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

// Vulnerable
const query = `SELECT * FROM users WHERE id = ${userId}`;

// Safer with node-postgres
const result = await pool.query(
  "SELECT * FROM users WHERE id = $1",
  [userId]
);

​

4. Authorization by Default

​

Patterns

• Deny by default.
• Centralize authorization checks where practical.
• Check object ownership, not just route access.
• Use least privilege roles.
• Re-check authorization after state changes.
• Log authorization failures.

​

Anti-Pattern

​

5. Secrets Management

​

Where Secrets Belong

​

Secret Hygiene

• Never hardcode secrets.
• Never commit .env files.
• Scan commits with tools such as gitleaks, trufflehog, or detect-secrets.
• Use short-lived credentials where possible.
• Scope tokens narrowly.
• Rotate secrets after exposure.
• Separate development, staging, and production secrets.

​

6. Dependency Security

​

Supply Chain Risks

• Known vulnerable dependency versions.
• Typosquatted packages.
• Compromised maintainer accounts.
• Malicious install scripts.
• Dependency confusion between public and private package names.
• Auto-updates that pull unreviewed code.
• Abandoned packages with no security fixes.

​

Controls

• Use lockfiles for reproducible installs.
• Review dependency diffs in pull requests.
• Run dependency scanning in CI.
• Remove unused packages.
• Prefer packages with active maintainers and clear ownership.
• Use private package namespaces to reduce dependency confusion.
• Restrict install scripts where possible.
• Monitor package publishes for unexpected releases.

​

7. Software Provenance and Build Integrity

​

Practices

• Use protected branches.
• Require code review for critical paths.
• Require signed commits or signed releases where appropriate.
• Generate SBOMs for releases.
• Produce build attestations for important artifacts.
• Keep build logs.
• Isolate CI runners.
• Do not expose production secrets to untrusted pull request workflows.
• Pin third-party CI actions to specific versions or commits.

​

8. CI/CD Security

​

CI/CD Controls

• Require branch protection on main branches.
• Use least-privilege service accounts.
• Separate build, test, staging, and production permissions.
• Avoid long-lived deployment tokens.
• Restrict who can modify workflows.
• Protect self-hosted runners.
• Require manual approval for production deploys when risk is high.
• Log secret access and deployment activity.
• Scan artifacts before release.

​

Pull Request Safety

• Do not expose secrets to untrusted PRs.
• Use read-only tokens for validation jobs.
• Require maintainer approval before running privileged jobs.
• Review workflow changes carefully.

​

9. Secure Error Handling

# Bad: leaks internals to users
except Exception as e:
    return {"error": str(e)}

# Better: log details server-side, return a generic message
except Exception as e:
    logger.exception("Database operation failed")
    return {"error": "An internal error occurred. Please try again later."}

• Never show stack traces to end users.
• Do not return database URLs, file paths, secrets, or internal hostnames.
• Log enough detail for investigation.
• Use correlation IDs so support can connect user reports to logs.
• Fail closed for authentication and authorization errors.

​

10. Security Logging and Detection

• Login success and failure
• MFA enrollment and disablement
• Password reset requests and completion
• Session revocation
• Role changes
• Permission changes
• API key creation and use
• OAuth app approvals
• Data exports
• Webhook failures
• Package publish events
• CI/CD workflow changes

• Passwords
• Session cookies
• MFA codes
• API tokens
• Full payment details
• Sensitive personal data unless there is a clear need and protection

​

11. Threat Modeling

• Authentication flows
• Admin panels
• Data export features
• Webhooks
• AI agent tools
• CI/CD workflows
• Package publishing
• Third-party integrations

​

Secure Coding Checklist

• Validate input server-side.
• Encode output by context.
• Use parameterized queries.
• Enforce authorization on the server.
• Store secrets outside code.
• Use least-privilege tokens.
• Scan for secrets before commit.
• Review dependency changes.
• Protect CI/CD workflows and runners.
• Log security events.
• Threat model sensitive workflows.

​

Practical Lab Ideas

1. Add server-side validation to an API route.
2. Fix an XSS bug by using contextual output encoding.
3. Replace a vulnerable SQL query with a parameterized query.
4. Add object-level authorization to an endpoint.
5. Run a secret scanner on a sample repository.
6. Create an SBOM and inspect transitive dependencies.
7. Harden a CI workflow so untrusted PRs cannot access secrets.
8. Threat model a package publishing workflow.

​

Key Takeaways

1. Secure coding includes the build and release path.
2. Authorization must be server-side and object-aware.
3. Secrets need lifecycle management, not just hiding.
4. Dependencies and extensions are attack surface.
5. CI/CD deserves the same security attention as production.
6. Good logs make response possible.
7. Threat modeling catches missing controls before attackers do.