Cybersecurity Guide for Developers: Threats, Defenses, and Secure SDLC

Introduction

We have triaged breaches that started with a missing auth check on one API route, a secret in a public repo, and a dependency two years out of date — not sophisticated nation-state exploits. Application security is mostly discipline on fundamentals that developers control daily.

This guide maps threats developers actually face, defenses that work in production codebases, and how to embed security into design, review, CI, and response without stopping delivery entirely.

Key takeaways

• Broken access control and injection remain top risks — verify authz server-side on every sensitive path.
• Secrets belong in secret managers, never in git — scan commits and CI for leaks.
• Dependencies are attack surface — automate patch PRs and review major upgrades.
• Security headers and HTTPS are baseline, not optional hardening.
• LLM features add prompt injection and data leakage risks — treat user content as hostile.
• Incident response starts with logging, ownership, and practiced runbooks — not panic.
• Security is proportional — prioritize assets by impact and likelihood.

Who is this guide for?

• Full-stack and backend developers shipping internet-facing applications
• Tech leads writing secure coding standards for a growing team
• DevOps engineers integrating security scans into CI/CD
• Teams without a dedicated AppSec function who still need a defensible posture
• Developers adding AI features who must understand new attack surfaces

When should you NOT use this?

• Air-gapped embedded systems with separate threat models — physical access and firmware signing dominate; web patterns are insufficient alone.
• Replacing legal/compliance programs — SOC 2 and GDPR need policy and process beyond code patterns.
• Penetration test report item-by-item without prioritization — fix critical exploitable paths first, not every informational finding.
• Security theater — checkbox scans without fixing findings waste time and create false confidence.
• Blocking all delivery for theoretical risks — risk-based prioritization keeps security sustainable.

Threat model for application developers

Think in assets, entry points, and trust boundaries.

Trust rule: never trust client-side checks, hidden form fields, or JWT claims without server validation against current user state.

OWASP-aligned priorities for builders

Focus engineering effort where exploitation impact is highest.

Authentication and session security

Multi-factor authentication on admin and high-value accounts is baseline for B2B products — not a premium feature.

Input validation and output encoding

Validate on server; treat all input as hostile — including JSON bodies, headers, and file uploads.

Upload limits: size, MIME sniffing, virus scan for user-facing file storage; store outside web root.

Secrets and configuration

Run secret scanners on pre-commit and CI. Rotate immediately on leak — revocation, not hope.

Supply chain and CI security

• Lockfiles committed; CI installs from lockfile only
• SBOM export for release artifacts when customers require it
• Signed commits or protected branches on main
• Minimal CI permissions — read-only default; deploy role only on release job
• Third-party GitHub Actions pinned to SHA, not floating @v1

Review new dependencies: maintenance status, download stats anomalies, typosquatting on package names.

AI-specific security notes

Products using LLMs face additional paths:

• Prompt injection — user content instructing model to ignore policy or exfiltrate data
• Tool abuse — agents calling tools with escalated scope
• Training data leakage — sending secrets or PII in prompts to consumer APIs
• Insecure generated code — weak crypto snippets, SQL string concat

Mitigations align with our AI coding guide: review all AI output, least-privilege tools, no secrets in prompts, human gates on destructive actions.

Real-world use cases

API authz audit on new feature

Checklist on every route: authenticate, authorize resource ownership, audit log sensitive reads, rate limit brute force.

Dependency CVE fire drill

Automated PR bumps patch version; integration tests run; deploy within SLA; postmortem if exploit window was public.

Secrets leak response

Revoke key in cloud console, rotate all related credentials, scan git history, notify if external exposure confirmed.

Pre-launch security headers

CSP, HSTS, X-Content-Type-Options, frame ancestors — verified in staging with securityheaders.com or equivalent scan.

LLM support bot hardening

User message sanitized; retrieval filtered by tenant; no tool access to admin APIs; escalation to human on policy triggers.

Best practices

1. Authz on server for every mutation and sensitive read — UI hiding is not security.
2. Parameterized data access — no exceptions for "quick" admin queries.
3. Rotate and scope secrets — short-lived credentials where cloud supports it.
4. Security in code review checklist — auth, input, secrets, dependencies on risky PRs.
5. Automate patch PRs — humans merge, bots detect CVEs.
6. Log auth failures and admin actions — with retention and alert thresholds.
7. Practice incident runbooks — table top twice a year minimum.

Common pitfalls

JWT in localStorage for XSS-vulnerable SPAs

One XSS steals token. Prefer HttpOnly cookies with CSRF protection for cookie-based sessions.

CORS * with credentials

Misconfigured cross-origin access. Explicit allowlist only.

Security by obscurity on admin routes

/admin unauthenticated — scanners find it in hours. Real auth required.

Ignoring dependency dev tree

Dev dependency CVE in CI pipeline can compromise builds. Scan all trees.

Verbose error messages to clients

Stack traces reveal framework versions and paths. Generic client message; detail in server logs.

Skipping authz tests

Unit test happy path only; IDOR ships to production.

Decision checklist

• Threat sketch completed for features handling PII, payments, or admin actions
• Server-side authorization on all sensitive endpoints verified
• Passwords hashed with modern algorithm; sessions use secure cookie flags
• Input validation on server for all external input sources
• SQL access parameterized; no dynamic query concat
• Secrets in manager; scanners run on CI
• Dependencies monitored; critical CVE SLA defined
• Security headers configured and verified in staging
• CI uses least privilege; third-party actions pinned
• Security events logged with appropriate retention
• Incident runbook with contacts and revocation steps documented
• AI features reviewed for injection and data leakage if applicable

Related articles

• AI coding guide for developers — secure workflows for AI-assisted code changes
• AI agents explained: architecture and production patterns — securing tool-using agent systems
• Modern software engineering guide — secure SDLC within broader engineering practice

Conclusion

Application security is executed in pull requests: auth checks, validated input, patched dependencies, and secrets kept out of git. Fancy tools do not compensate for missing fundamentals.

Prioritize by exploitability and asset value. Automate repetition in CI; keep human judgment on design and review. When something breaks, logs and runbooks matter as much as prevention.