The Security Checklist I Use for Every Website I Build

As someone who's been building websites for less than a year, I've quickly learned that security isn't something you can ignore or add later. Recently, I dove deep into JWT and OAuth implementations, and I want to share the practical security checklist I've developed through research and hands-on experience.

Why I Started Taking Security Seriously

When I first started building web applications, I'll be honest—authentication seemed like a nice-to-have feature. But after researching recent vulnerabilities and understanding how easily things can go wrong, I realized that security needs to be built into every project from day one.

Understanding Modern Authentication: My Learning Journey

Think of JSON Web Tokens (JWTs) as digital passports for your application. Just like a passport contains verified information about a traveler and allows them to cross borders, a JWT contains verified claims about a user and allows them to access different parts of your application.

Here's what I learned about choosing the right authentication method:

When to Use What: A Beginner's Guide

High Security Projects: OAuth 2.0 or mTLS (Mutual Transport Layer Security) are your best bets. If you're building anything handling sensitive data, mTLS using certificates for mutual verification is essential.

Scalable Applications: JWT or Bearer Authentication work best. JWT's stateless nature makes it perfect for microservices and distributed systems.

Simple Projects: API Keys can work for basic internal tools, but only for low-security scenarios.

Identity Management: OpenID Connect, which builds on OAuth 2.0 and adds identity verification.

My JWT Security Research and Implementation

Understanding JWT Structure

Every JWT follows this three-part structure:

• Header: Specifies cryptographic algorithms (the alg parameter defines signing mechanisms like HMAC or RSA)
• Payload: Contains claims (registered, public, and private claims)
• Signature: Ensures integrity through cryptographic signing

Critical Security Measures I Always Implement

Always Validate the JWT Issuer
This is something I learned the hard way through research. The iss claim should always be checked against an allow-list. When your application consumes a JWT, it must verify the token was issued by an expected authorization server. If someone sends a forged JWT with their own issuer, and your app dynamically downloads keys from that issuer, you'll validate forged JWTs as genuine.

Implement Proper Time Controls

• Expiration Time (exp): Set reasonable expiration times—not too short to annoy users, not too long to create security risks
• Issued At (iat): Always validate when the token was issued to prevent replay attacks

Plan for Key Rotation
Based on my research, automated key rotation is crucial. Keys should rotate regularly, and you need a system to handle the transition period where both old and new keys are valid.

Recent Vulnerability Lessons

CVE-2025-30144: The Issuer Validation Trap
While researching JWT security, I discovered this vulnerability in the fast-jwt library. It revealed a subtle but dangerous flaw in issuer claim validation where the library incorrectly accepted arrays of strings as valid issuer values, allowing attackers to include both legitimate and malicious issuers in the same token.

The Lesson: Always implement the principle of least privilege in your JWT claims, and validate not just that the token is authentic, but that it grants appropriate access for the specific resource being requested.

My Security Implementation Process

Step 1: Choose the Right Authentication Method

I evaluate each project based on:

• Security Requirements: Public-facing vs. internal applications
• Scalability Needs: Single server vs. distributed systems
• Integration Complexity: Third-party services vs. self-contained systems
• Performance Requirements: High-throughput vs. standard load

Step 2: Implement JWT Best Practices

Base64URL Encoding
JWTs use Base64URL encoding to ensure URL-safe transmission. This variant replaces standard Base64 characters + and / with - and _ respectively, making tokens safe for URLs.

Signature Verification
Every time a JWT is received, the server recalculates the signature using its key and compares it with the token's signature. Match = valid token. No match = reject immediately.

Secure Transmission
Always use HTTPS when transmitting OAuth2 tokens and authorization codes. This isn't optional—it's fundamental.

Step 3: Security Hardening

1. Understanding Stateless vs. Stateful

• Stateful: Server-side session management with unique session identifiers
• Stateless: Application stores session information as signed/encrypted tokens

For scalable applications, I usually go with stateless JWT authentication.

2. Payload Security
I organize JWT claims carefully:

• Registered claims: Standard fields like iss, sub, and exp
• Public claims: Customizable names defined in the IANA registry
• Private claims: Organization-specific data agreed upon by parties

3. Additional Security Measures

• Implement security testing in development workflows
• Use static code analysis tools to detect vulnerabilities early
• Set up monitoring and logging for all authentication attempts
• Plan for regular security reviews

What I've Learned About Implementation

For Different Application Types

High-Traffic Applications: Use JWT for its stateless nature, but implement proper caching strategies for signature verification to avoid performance bottlenecks.

Multi-User Applications: Implement user isolation at the JWT level with proper claim validation. Each user should have isolated access scopes.

Mobile Applications: Implement token refresh strategies that don't require users to re-authenticate frequently while maintaining security.

Common Mistakes I've Learned to Avoid

Through my research and development experience, here are the pitfalls I watch out for:

1. Never trust frontend validation alone—always validate on the server
2. Don't store sensitive data in JWT payloads—they're Base64 encoded, not encrypted
3. Implement proper error handling that doesn't leak information about your authentication system
4. Use HTTPS everywhere—no exceptions
5. Plan for key rotation from day one—don't make it an afterthought

My Testing Approach

Before any application goes live, I run through this security testing checklist:

1. Token Manipulation Tests: Try to modify tokens and verify they're rejected
2. Expiration Testing: Ensure expired tokens are properly rejected
3. Issuer Validation: Test with tokens from unauthorized issuers
4. Scope Testing: Verify users can't access resources outside their permissions
5. Performance Testing: Ensure authentication doesn't become a bottleneck

Key Takeaways from My Research

Security isn't just about implementing the latest authentication technology—it's about understanding the threats, choosing appropriate solutions, and implementing them correctly. JWT and OAuth are powerful tools, but like any tool, they're only as good as the implementation.

Through my research on recent vulnerabilities and best practices, I've learned that:

• Defense in depth is crucial—layer multiple security measures
• Stay updated on new vulnerabilities and patches
• Validate everything twice, especially user input and token claims
• Document your security decisions so you can review and improve them

Moving Forward

As I continue building and learning, this checklist evolves. Security is an ongoing process, not a one-time implementation. The key is staying informed about new threats, following established best practices, and always assuming that security threats will evolve.

My approach is simple: research thoroughly, implement carefully, test extensively, and never stop learning. Every application deserves proper security, and following this checklist has helped me build that into my development process from the start.

---

Security is a journey, not a destination. Stay curious, stay updated, and always validate your assumptions.