BiTree
  • Search For Lessons
  • Curriculum
  • Pricing
  • For Educators
  • Become a Tutor
  • About
  • Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
BiTree

Live coding lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Search For Lessons
  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Become a Tutor
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 BiTree. All rights reserved.
Curriculum/Web Development/Security for Developers/Capstone: Harden a Deployed App
120 minAdvanced

Capstone: Harden a Deployed App

After this lesson, you will be able to: Harden a real deployed web application end to end, applying every defense in this subtrack, and produce a short security writeup you can show an employer.

Pick a real app (your own, or a sample Next.js app) and harden it across every layer this subtrack covered. The deliverable is a deployed app that scores an A on securityheaders.com plus a one-page security writeup describing what you hardened and why. This is portfolio gold: it proves you ship secure-by-default code.

Prerequisites:HTTPS, TLS, and DNS Security

The brief

Start from a deployed Next.js app with at least a login form and one API route (build a tiny one if you do not have it). Your job is to harden it: secrets, rate limiting, bot protection, headers, authentication, dependencies, and HTTPS. Then write up what you did. The point is not a flashy feature; it is demonstrating the security discipline employers actually want.

Build milestones

Work through these in order; each maps to a lesson.

  1. 1

    1. Secrets: move every key to environment variables, add .env.example + .gitignore, and run a secret scan over history.

  2. 2

    2. Rate limiting: add a sliding-window limit to the login and any write endpoint with Upstash Redis, returning 429 + Retry-After.

  3. 3

    3. Bot protection: add Turnstile to the login/signup form with server-side verification, plus a honeypot field.

  4. 4

    4. Headers: add the full security-header block in next.config.js and reach an A on securityheaders.com.

  5. 5

    5. Auth: confirm passwords are hashed with Argon2id/bcrypt, cookies are HttpOnly+Secure+SameSite, and add TOTP MFA if time allows.

  6. 6

    6. Dependencies: run npm audit, fix what you safely can, enable Dependabot, and document any accepted risk.

  7. 7

    7. HTTPS/DNS: confirm HTTPS is enforced (HSTS), Cloudflare is in Full Strict mode if used, and the registrar has MFA.

Deliverable and submission

Deploy the hardened app (Vercel is fine). Write a one-page SECURITY.md in the repo: for each of the seven areas, one or two sentences on what you did and the threat it addresses. Include your securityheaders.com grade as a screenshot or link. Push it all to a public GitHub repo with a clear README.

How to talk about this in an interview

Lead with the outcome: 'I hardened a deployed app across seven security layers and documented the threat model.' Then pick one area to go deep on, ideally headers/CSP or authentication, because those generate good follow-up questions. On a resume: 'Hardened a production Next.js app (CSP, HSTS, rate limiting, Argon2id auth, dependency scanning); achieved an A rating on securityheaders.com.' Expect questions like: why report-only CSP first, why Argon2id over SHA-256, and how rate limiting defeats credential stuffing. You have answers to all three from this subtrack.

💡 Common mistakes only experienced devs catch

Hardening locally but never verifying on the deployed URL (headers are often set by the host, not your dev server). Adding a CSP that breaks the app and disabling it instead of using report-only. Claiming MFA in the writeup without actually testing the enroll-and-verify flow. Forgetting that the writeup itself is the most valuable artifact to an interviewer; do not skip it.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←HTTPS, TLS, and DNS Security
Back to Security for Developers
Job Readiness: Secure Development Roles→