Author: ignacy130

In the world of application development, rate limiting often gets overlooked until something goes wrong. Whether it’s a surge in legitimate traffic crashing your servers or malicious actors attempting to exploit your API, rate limiting serves as a critical first line of defense. This article explores why implementing rate limiting is essential for both application performance and security.

What Is Rate Limiting?

Rate limiting restricts how many requests a user, device, or IP address can make to your application within a specific time frame. When a client exceeds the defined threshold, subsequent requests are either rejected, delayed, or queued until the next time window.

Performance Benefits of Rate Limiting

Your application servers have finite resources—CPU, memory, database connections, and network bandwidth. Without rate limits, a single client can consume a disproportionate share of these resources, potentially degrading service for everyone else.

Preventing Resource Exhaustion

Without rate limits, a single client can consume disproportionate server resources, whether intentionally or accidentally. Consider these scenarios:

• A mobile app with a bug that triggers repeated API calls
• A misconfigured integration partner hammering your endpoints
• A spike in user activity during a marketing campaign

Rate limiting ensures that your application resources remain available to all users by preventing any single client from monopolizing your infrastructure.

Controlling Infrastructure Costs

In cloud environments where you pay for compute resources and data transfer, unchecked API usage directly impacts your bottom line. Rate limiting helps maintain predictable infrastructure costs by:

• Preventing unexpected traffic spikes from scaling up resources unnecessarily
• Reducing bandwidth costs from excessive API calls
• Minimizing database connections and query loads

Improved User Experience

While it might seem counterintuitive, rate limiting actually improves overall user experience by:

• Maintaining consistent response times during peak loads
• Preventing service degradation that affects all users
• Reducing database contention that leads to slow queries

Security Benefits of Rate Limiting

Mitigating Brute Force Attacks

Brute force attacks rely on making repeated requests to guess passwords or access tokens. Rate limiting dramatically increases the time required for these attacks to succeed, often making them impractical to continue.

Preventing Credential Stuffing

Attackers use automated tools to try username/password combinations from data breaches across multiple services. Rate limiting makes this type of attack difficult to execute at scale.

Thwarting Scraping and Data Harvesting

Rate limiting is your first defense against bots designed to extract large amounts of data from your application, protecting your intellectual property and user information.

Reducing Impact of DDoS Attacks

While not a complete solution, rate limiting can help mitigate the impact of certain types of Distributed Denial of Service (DDoS) attacks by limiting the effectiveness of each attacking node.

Implementing Effective Rate Limiting

Choose the Right Limiting Strategy

The simplest rate limiting strategy can limit requests from IP of the requester.

However several other rate limiting strategies exist, each with its own advantages:

• Fixed Window: Simplest approach, counts requests in fixed time intervals
• Sliding Window: More sophisticated, tracks requests across overlapping time periods
• Token Bucket: Allows for bursts of traffic while maintaining overall limits
• Leaky Bucket: Processes requests at a constant rate, queueing or dropping excess

Consider Multiple Dimensions

Effective rate limiting often operates on multiple dimensions:

• Per IP address: Protects against distributed attacks
• Per user/API key: Ensures fair usage among authenticated users
• Per endpoint: Provides extra protection for sensitive or resource-intensive operations
• Per content type: Prevents abuse of specific features (e.g., file uploads)

Communicate Limits Clearly

When clients reach rate limits, provide clear feedback:

• Return standard HTTP 429 (Too Many Requests) status codes
• Show a small but clear information on user interface – it’s rather unusual for a standard user to exhaust the limit manually but may happen depending on a resources usage in your web application and limit you apply. Inform when the user should try again.
• Include headers indicating current limits and remaining quota
• Provide documentation on rate limits for developers integrating with your API

Set Appropriate Thresholds

Rate limits should balance protection with legitimate usage patterns:

• Public endpoints: Lower limits (e.g., 60 requests per minute)
• Authenticated endpoints: Moderate limits (e.g., 300 requests per minute) – that may seem excessive but remember that opening a single page in a modern web app can result in several API requests
• Essential operations: Higher limits or special exceptions
• Resource-intensive operations: Stricter limits

Start with higher limits to avoid annoying your visitors and users and monitor which limits are too high.

Common Pitfalls to Avoid

Setting Universal Limits

One-size-fits-all rate limits rarely work well. Different API endpoints have different resource requirements and security considerations. Tailor your limits accordingly.

Ignoring Legitimate Use Cases

Implement mechanisms to handle exceptional but legitimate traffic spikes:

• Offer increased limits for premium users
• Provide burst capacity for predictable high-traffic events
• Create whitelist mechanisms for trusted partners

Distributed System Challenges

In distributed architectures, rate limiting requires special consideration:

• Ensure rate limit counters are shared across all application instances
• Consider using Redis or similar distributed caching solutions
• Account for clock drift between servers

Forgetting Internal Traffic

Remember to account for your own internal services when setting limits. Monitoring tools, batch processes, and microservices can generate significant traffic.

Getting Started

Adding basic rate limiting can be as simple as adding middleware to your application. Most web frameworks offer straightforward solutions:

• Express (Node.js): express-rate-limit
• Django (Python): django-ratelimit
• Rails (Ruby): rack-attack
• Laravel (PHP): Built-in throttle middleware
• Spring Boot (Java): bucket4j

These implementations typically require just a few lines of configuration code to activate.

Conclusion

Rate limiting is not merely a defensive measure—it’s an essential component of a well-designed application architecture. By implementing thoughtful rate limiting strategies, you simultaneously protect your application’s performance, control operational costs, and bolster security against a wide range of threats.

Whether you’re building a new application or enhancing an existing one, rate limiting deserves a prominent place in your development roadmap. The small investment in implementation pays dividends in application stability, security, and user satisfaction.

As we conclude our series on secure coding fundamentals, let’s address the most common authorization pitfalls that can undermine even well-designed permission systems. Recognizing these issues early can save you considerable headaches and security incidents down the road.

Missing Authorization Checks

Perhaps the most dangerous pitfall is simply forgetting to check permissions at all. This often happens when:

• New endpoints or features are added without security reviews
• Developers assume framework middleware will handle all checks
• Legacy code paths bypass your permission system
• API endpoints are created for internal use but exposed publicly

Mitigation: Implement automated testing that verifies authorization checks are present. Consider using static analysis tools that flag endpoints without authorization logic.

Relying on Client-Side Authorization

A surprisingly common mistake is implementing authorization logic only in the UI:

• Buttons and menu items are hidden for unauthorized users
• But the underlying API endpoints remain accessible
• Attackers can simply make direct API calls, bypassing the UI restrictions

Mitigation: Always enforce permissions on the server side. Treat UI-based permission enforcement as a convenience feature only.

Horizontal Privilege Escalation

This occurs when users can access resources belonging to other users at the same permission level:

• User A can view User B’s private data by manipulating URL parameters
• Resource IDs are predictable or enumerable
• Authorization checks verify only that a user has permission to access a type of resource, not a specific instance

Mitigation: Implement resource ownership checks alongside role-based permissions.

Insufficient Granularity

Permission systems often start too simple and become security liabilities:

• All-or-nothing admin accounts with excessive privileges
• Permissions that are too broad (e.g., “manage_content” rather than “edit_document”)
• No way to limit access to specific resources or data subsets

Mitigation: Design permissions to be specific and combinable. Use attribute-based access control alongside roles for fine-grained permissions.

Forgetting About Indirect Access

Users may gain unintended access through indirect means:

• Export functions that dump data beyond what a user should see
• Report generators that aggregate restricted information
• Search functionality that returns results from restricted resources
• Public API endpoints that leak sensitive information in error messages

Mitigation: Apply authorization checks to all data access paths, including exports, reports, and search results.

Insecure Permission Changes

The process of changing permissions itself must be secure:

• Missing audit trails for permission changes
• No approval workflows for sensitive permission grants
• Self-service role assignment without proper verification
• Lack of notifications for security-critical permission changes

Mitigation: Log all permission changes, implement approval workflows for sensitive roles, and notify security stakeholders of significant permission changes.

The Stale Permissions Problem

Permission systems often fail to account for changing circumstances:

• Users retain access long after changing roles
• Temporary access becomes permanent
• Permissions aren’t revoked when projects end
• “Break glass” emergency access isn’t reviewed or revoked

Mitigation: Implement permission expiration, regular access reviews, and automated cleanup of unused accounts and roles.

Closing Thoughts

Building secure authorization isn’t just about implementing the right pattern—it’s about maintaining vigilance throughout your application’s lifecycle. By understanding these common pitfalls and proactively addressing them, you’ll create more resilient applications that protect your users’ data and maintain their trust.

Thank you for following this secure coding series. Remember that security is a journey, not a destination—continuously revisit your permission systems as your application evolves to ensure they remain effective and appropriate.

When designing a permission system, the architecture you choose shapes how your application handles security for months or years to come. Let’s explore the fundamental concepts of implementing permissions and how they relate to roles, independent of any specific language or framework.

Core Permission Concepts

At its heart, a permission system answers one question: “Is this action allowed?” To answer this question effectively, we need several key components:

1. Resources

Resources are the objects or entities that users interact with in your system. These might be:

• Data entities (documents, products, user profiles)
• System features (reports, dashboards, admin panels)
• Operations (payment processing, account management)

2. Actions

Actions define what can be done to resources:

• Read/View
• Create
• Update/Edit
• Delete
• Approve
• Share/Assign

3. Permissions

A permission is the combination of an action on a resource. Examples include:

• view_document
• edit_product
• delete_user
• run_report

Relating Permissions to Roles

Roles serve as collections of permissions that represent common user responsibilities. A well-designed system keeps these relationships clean and maintainable:

Role-Permission Mapping

The most common approach is to create a many-to-many relationship between roles and permissions:

• A role can have multiple permissions
• A permission can belong to multiple roles

For example:

• Admin role: [create_user, edit_user, delete_user, view_analytics]
• Editor role: [edit_document, publish_document]
• Viewer role: [view_document]

Permission Checking Models

When implementing permission checks, you have several patterns to consider:

1. Direct Permission Checks

Check if a user has a specific permission directly:

if (userHasPermission(currentUser, "edit_document"))

2. Role-Based Checks

Check if a user belongs to a role with the required permission:

if (userHasRole(currentUser, "editor") || userHasRole(currentUser, "admin"))

3. Resource-Specific Permissions

For more granular control, permissions can be scoped to specific resources:

if (canUserAccess(currentUser, "edit", documentId))

Storage Strategies

How you store permissions and roles affects both performance and flexibility:

1. Database Tables: Most common approach with tables for users, roles, permissions, and their relationships
2. Config Files: For smaller applications with static permissions
3. In-Memory Structures: For high-performance applications that can reload permission data

Common Implementation Patterns

Regardless of your technology stack, these patterns help build maintainable permission systems:

Permission Guards

Centralize permission checks in “guard” functions that run before actions:

function guardResourceAccess(user, action, resource) {
  if (!hasPermission(user, action, resource)) {
    throw new AccessDeniedError();
  }
}

Permission Decorators

Wrap functions that need protection with permission requirements:

@requiresPermission("edit_document")
function editDocument() {
  // Function code
}

Permission Inheritance

Allow roles to inherit permissions from other roles to reduce duplication:

• Admin inherits all Editor permissions
• Editor inherits all Viewer permissions

Best Practices

1. Default to Deny: Users should have no permissions by default
2. Principle of Least Privilege: Grant only the permissions necessary for users to perform their functions
3. Separation of Duties: Critical operations should require multiple roles
4. Regular Auditing: Review permission assignments periodically

By understanding these core concepts, you can implement a permission system that grows with your application, regardless of which technologies you eventually choose.

Even the smallest applications can benefit from thoughtful permission structures. In this guide, we’ll explore how Role-Based Access Control (RBAC) provides a clean, scalable approach to managing who can do what in your application—without creating a maintenance nightmare.

What is RBAC?

Role-Based Access Control is a security model that restricts system access based on the roles of individual users. Instead of assigning permissions directly to users, you assign users to roles, and then grant permissions to those roles.

Why RBAC Makes Sense for Small Apps

Many developers skip proper access control systems when building small applications with just a handful of user types. This seems logical at first—why add complexity when you only need “admin” and “user” roles?

Here’s why it’s worth implementing RBAC from the start:

1. Cleaner Code: Rather than sprinkling if (user.isAdmin) checks throughout your codebase, RBAC creates a centralized permission system that’s easier to maintain.
2. Future-Proofing: Small apps have a funny way of growing. What starts as “just admin and user roles” inevitably expands to include moderators, editors, or department-specific access. RBAC scales without major refactoring.
3. Security by Design: Implementing RBAC forces you to think deliberately about which functions need protection, reducing the risk of accidentally exposing sensitive operations.
4. Easier Testing: With clearly defined roles and permissions, you can more easily test that your authorization logic works correctly.

Basic RBAC Implementation

A simple RBAC system for a small app might look like:

1. Define roles (e.g., Admin, Editor, User)
2. Define permissions (e.g., create_post, delete_user, view_analytics)
3. Assign permissions to roles
4. Assign roles to users
5. Check permissions before performing actions

Even with just 2-3 roles, this structured approach pays dividends in code organization and security.

When building web applications, one of the most common security mistakes made by new developers is relying solely on client-side (frontend) validation. While frontend validation improves user experience by providing immediate feedback, it should never be your only line of defence. Let’s explore why backend validation is absolutely essential and what risks you face without it.

The Illusion of Security

Frontend validation works something like this: you build a beautiful signup form with JavaScript that checks if an email address is properly formatted, passwords meet complexity requirements, and users don’t enter special characters in their names. The form shows helpful error messages and prevents submission until everything looks good.

This creates an illusion of security. The problem? Any client-side validation can be completely bypassed.

Why Frontend Validation Can Be Bypassed

Here’s the reality: anything happening in the browser is under the user’s control, not yours. Users can:

1. Disable JavaScript entirely
2. Use browser developer tools to modify your validation code
3. Bypass your frontend completely and send requests directly to your API
4. Use tools like Postman or curl to craft custom requests

This means that any validation you implement in the browser can be circumvented by a determined user with basic technical knowledge.

Examples of Frontend-Only Validation Failures

The following examples were not taken from real-life. But situations similar to them happened in a lot of websites and apps. One should really care about securing mobile apps APIs where the frontend, an app on the smartphone, seemingly is not easy to change. But communications with backend is usually still the same: some http requests which can be hijacked and manipulated anyway.

Example 1: The $10,000 Shopping Cart

A small e-commerce site implemented price calculations on the frontend. When users added items to their cart, JavaScript calculated the total. The checkout endpoint only received the final total, not individual item prices.

An attacker opened the browser’s developer console and modified the JavaScript that calculated the cart total. They added $10,000 worth of products but changed the total price sent to the server to $10. Without backend validation to recalculate the order total based on the actual items, the order was processed at the fraudulent price.

Example 2: The Admin Promotion

A startup built a user management system where user roles were displayed or hidden in the UI based on the user’s current role. Regular users couldn’t see the “Promote to Admin” button in the interface.

However, a curious user inspected network requests and discovered the API endpoint /api/users/{id}/promote. Using a simple curl command, they sent a POST request to this endpoint for their own user ID. Since the developers assumed the button’s visibility was sufficient protection, they didn’t implement permission checks on the backend. The user successfully promoted themselves to admin.

Example 3: The Form Field Limit Bypass

A job application site limited cover letters to 500 characters on the frontend to keep applications concise. The validation was implemented with JavaScript that counted characters and disabled the submit button if the limit was exceeded.

Applicants who wanted to submit longer cover letters simply modified the page using browser developer tools to remove the character limit. Without corresponding backend validation, the server accepted cover letters of any length, resulting in some submissions that were thousands of characters long, breaking the site’s layout and frustrating recruiters.

Common Vulnerabilities When Backend Validation Is Missing

1. Data Integrity Issues

Without backend validation, you cannot guarantee the integrity of data entering your system. This leads to:

• Malformed data breaking functionality
• Inconsistent information in your database
• Potential for injection attacks if data is used in database queries

2. Business Rule Violations

Your application likely has important business rules that must be enforced:

• Discount codes have usage limits
• Free trial accounts can only create a certain number of projects
• Premium features are only available to paying customers

Without backend validation, these rules can be circumvented.

3. Security Vulnerabilities

Some of the most serious security issues stem from trusting client-side data:

• SQL injection when unvalidated data is used in database queries
• Cross-site scripting (XSS) when unvalidated data is displayed to users
• Server-side request forgery when unvalidated URLs are used
• Business logic bypasses leading to unauthorized actions

The Proper Approach: Defense in Depth

The secure approach is to implement validation at multiple levels:

1. Frontend Validation for User Experience

Keep your frontend validation! It’s valuable for:

• Providing immediate feedback to users
• Reducing server load from obviously invalid submissions
• Creating a polished, responsive experience

2. Backend Validation for Security

Then add comprehensive backend validation that:

• Treats all incoming data as untrusted
• Re-validates everything according to your business rules
• Sanitizes data before using it in database queries or displaying it
• Enforces permissions and access controls

3. Database Constraints as a Final Safety Net

Add a third layer of protection at the database level:

• Use proper data types (integers, dates, etc.)
• Add constraints (NOT NULL, UNIQUE, etc.)
• Implement referential integrity through foreign keys
• Set reasonable field size limits

Implementation Strategies

Here’s how to implement effective backend validation:

Use Validation Libraries

Most frameworks offer robust validation libraries:

• Express.js has express-validator
• Django has built-in form validation
• Laravel has the Validator class
• Ruby on Rails has ActiveRecord validations

Implement a Centralized Validation Layer

Process all incoming requests through a validation middleware that:

• Checks data types and formats
• Sanitizes inputs
• Validates business rules
• Rejects invalid requests before they reach your core logic

Validate Context, Not Just Content

Some validation requires context:

• Does this user have permission to access this resource?
• Is this action allowed at the current time?
• Does this operation make sense in the current state?

These contextual validations are particularly important and often overlooked.

Conclusion

Frontend validation is about user experience; backend validation is about security and data integrity. Both are necessary, but they serve different purposes.

Remember: Never trust user input, no matter where it comes from or how it’s been validated on the client side. Verify everything on the server before you act on it.

Building a secure application means implementing multiple layers of validation. Your users get the immediate feedback of frontend validation, while your application benefits from the security of backend validation. This defense-in-depth approach is the only way to truly protect your application and your users’ data.

As you build your first apps, you’ll frequently encounter the terms “authentication” and “authorization.” While these terms sound similar and are often used together (sometimes abbreviated as “auth”), they represent two distinct security processes. Understanding the difference between them is crucial for creating secure applications that protect both user data and your app’s functionality.

Authentication: Proving Who You Are

Authentication is the process of verifying who someone is.

Think of authentication as the bouncer at the club entrance checking IDs. The bouncer’s job at this stage is simple: determine if you are who you claim to be. They’re not yet deciding what you can do once inside—just whether you can enter at all.

In digital terms, authentication is how your app verifies a user’s identity. This typically happens at login, when a user provides credentials that prove they are who they claim to be.

Common Authentication Methods:

• Password-based authentication: Users provide a username/email and password
• Social login: Users authenticate through Google, Facebook, GitHub, etc.
• Biometric authentication: Fingerprint or facial recognition (common in mobile apps)
• Multi-factor authentication (MFA): Combining multiple methods, like a password plus a one-time code
• Magic links: Sending a login link to a verified email address

Authentication Examples:

1. Sarah logs into your photo sharing app by entering her email and password. The system checks these credentials against what’s stored in the database. This is authentication—confirming Sarah is really Sarah.
2. A banking app asks for your fingerprint before showing any account information. The app is authenticating you—verifying your identity—before proceeding.
3. You sign into a new service using “Login with Google.” You’re using Google to authenticate your identity to the new service.

Authorization: Determining What You Can Do

Authorization is the process of verifying what someone is allowed to do.

Continuing our club analogy: once past the bouncer, authorization is like the VIP wristband system inside. Regular wristbands might grant access to the main floor, while VIP wristbands allow entry to exclusive areas. Your wristband authorizes what you can access within the club.

In your app, authorization happens after authentication and determines what parts of the application and what data a user can access or modify.

Common Authorization Approaches:

• Role-based access control (RBAC): Permissions based on assigned roles (admin, editor, viewer)
• Attribute-based access control (ABAC): Permissions based on user attributes and environmental factors
• Permission flags: Specific permission settings for individual actions
• Resource ownership: Access controls based on who created or owns a resource

Authorization Examples:

1. Sarah has successfully logged into your photo sharing app (authentication), but she can only edit or delete her own photos, not anyone else’s. This permission check is authorization.
2. In a project management tool, team members can view all projects, but only project managers can create new projects or add team members. Both project managers and team members are authenticated users, but they have different authorizations.
3. An admin user in your app can access user management screens and modify system settings, while regular users cannot see these sections at all. The system is enforcing different authorizations based on user roles.

Why the Distinction Matters

Confusing authentication and authorization leads to common security mistakes:

Authentication Without Proper Authorization

Imagine building a social network where users can view profile pages at URLs like /profile/123. A new developer might check if a user is logged in (authenticated) before showing the page, but forget to verify whether the logged-in user should have access to that specific profile.

This creates an authorization vulnerability: any authenticated user could simply change the ID in the URL to access other users’ private profiles.

// BAD EXAMPLE - Authentication without authorization
function viewProfile(profileId) {
  if (isUserLoggedIn()) { // Authentication check
    // Missing authorization check!
    return getProfileData(profileId);
  } else {
    return "Please log in to view profiles";
  }
}

// GOOD EXAMPLE - Both authentication and authorization
function viewProfile(profileId) {
  if (!isUserLoggedIn()) { // Authentication check
    return "Please log in to view profiles";
  }
  
  if (canUserAccessProfile(currentUser, profileId)) { // Authorization check
    return getProfileData(profileId);
  } else {
    return "You don't have permission to view this profile";
  }
}

Authorization Checks Without Authentication

Another mistake is implementing authorization checks without ensuring proper authentication first. This happens when developers add code to check permissions but don’t verify the user’s identity.

For example, an API endpoint might check a user permission flag but not properly validate the authentication token, potentially allowing attackers to forge or manipulate requests.

Common Implementation Approaches

Authentication Implementation

Authentication typically happens at specific entry points in your application:

• Login pages
• API endpoints that issue tokens
• OAuth callback routes

Most frameworks provide authentication middleware that runs before your route handlers, ensuring a user is authenticated before proceeding further.

Authorization Implementation

Authorization usually occurs:

• Within individual route handlers or controllers
• At the database query level
• Via middleware that runs after authentication
• Through declarative rules in UI components

Many frameworks offer policy-based authorization systems that let you define rules centrally and apply them throughout your application.

Avoiding Common Auth Mistakes

1. Always authenticate before authorizing. It doesn’t make sense to check what someone can do until you know who they are.
2. Check authorization on every request, not just when rendering UI. An attacker might bypass your UI and make API requests directly.
3. Apply authorization checks at multiple levels for sensitive operations: in the UI (to provide a good user experience), in API controllers (to protect your service), and in database queries (as a final safety net).
4. Don’t rely on obscurity. Just because a button isn’t visible in the UI doesn’t mean the underlying functionality is protected.
5. Use your framework’s built-in auth systems rather than rolling your own. Authentication and authorization are complex security domains with many edge cases.

Conclusion

Authentication and authorization work together to create a secure application, but they serve distinct purposes. Authentication verifies identity (who you are), while authorization controls access (what you can do).

As you build your app, think about these processes separately:

1. How will users prove their identity to your system?
2. Once identified, what should different users be allowed to do?

By maintaining this clear distinction, you’ll create more secure applications and avoid common security pitfalls that could expose user data or allow unauthorized actions.

---

Sources:

• https://owasp.org/Top10/A01_2021-Broken_Access_Control/

Creating a secure authentication system is one of the first major challenges you’ll face when building an application. While authentication might seem straightforward on the surface, it involves numerous security considerations that can be difficult to get right. Let’s explore the most important concepts for implementing authentication in your app, regardless of which technology stack you’re using.

Leverage Your Framework’s Built-in Solutions

Most modern web frameworks come with robust authentication systems that have been tested, refined, and secured by thousands of developers over years of use. These built-in solutions handle complex security requirements so you don’t have to:

• Django offers Django Authentication which manages user accounts, groups, permissions, and cookie-based user sessions
• Ruby on Rails includes Devise, a flexible authentication solution
• Laravel provides a complete authentication system with just a few artisan commands
• Express.js has Passport, a comprehensive authentication middleware
• Spring offers Spring Security with extensive authentication support

Using these established solutions gives you the benefit of security best practices, regular updates, and community support. When a new authentication vulnerability is discovered, these frameworks typically release patches quickly, keeping your application protected.

Don’t Reinvent the Authentication Wheel

It’s tempting to build your own authentication system from scratch. It might seem simple enough—just compare a username and password, right? In reality, secure authentication involves:

• Password hashing with appropriate algorithms and salt
• Protection against timing attacks
• Session management
• CSRF protection
• Brute force prevention
• Password reset workflows
• Email verification
• Account lockout policies

Each of these components presents its own security challenges. Even experienced developers can introduce vulnerabilities when implementing these features from scratch. Unless you have a compelling reason to build custom authentication, use the tools your framework provides or reach for established authentication libraries.

Social Login: Reducing Friction While Maintaining Security

Integrating authentication with social providers like Google, Facebook, Apple, or GitHub can significantly improve your user experience:

Advantages of Social Login:

• Users don’t need to create and remember another password
• Many social providers already implement strong security measures like 2FA
• Reduced friction during signup leads to higher conversion rates
• Less sensitive data to store and manage on your end

Implementation Considerations:

• Stick closely to the official OAuth implementation guides provided by your framework
• Be aware that social providers may change their APIs, requiring updates to your integration
• Decide how to handle account linking (when a user tries to sign up with a social account that shares an email with an existing user)
• Always implement a fallback authentication method in case the social provider has an outage

Social Login Caveats:

• Your app becomes dependent on third-party services
• Users may have privacy concerns about connecting their social accounts
• You’ll have less control over the authentication process
• If a user loses access to their social account, they might also lose access to your app

When implementing social login, resist the urge to create custom OAuth flows. Instead, use your framework’s official integrations or well-maintained libraries designed specifically for this purpose.

Password Storage: If You Must Store Passwords

If you need to implement password-based authentication, proper storage is critical:

Do:

• Use modern hashing algorithms designed specifically for passwords (bcrypt, Argon2, PBKDF2)
• Include a unique salt for each password to prevent rainbow table attacks
• Set appropriate work factors that balance security and performance
• Increase work factors as computing power increases over time

Don’t:

• Store passwords in plaintext (ever!)
• Use general-purpose hashing algorithms like MD5 or SHA-1
• Encrypt passwords instead of hashing them
• Store password hints in a way that could expose user passwords

Most authentication modules in modern frameworks handle proper password hashing automatically. If you use these tools as intended, you’ll benefit from secure password storage without having to implement the cryptography yourself.

Tokens vs. Sessions

For API authentication, avoid requiring the user to send their username and password with every request. Instead, use token-based authentication:

• Session tokens: Server-side sessions with a session ID stored in a cookie
• JWT (JSON Web Tokens): Self-contained tokens that can be validated without hitting a database
• OAuth 2.0 tokens: For API access and integration with other services

Tokens provide a secure way to authenticate requests without repeatedly handling sensitive credentials. They can also include expiration times and can be revoked if necessary.

Email Verification: Confirming User Identity

Email verification adds an important layer of security by confirming that users have access to the email address they provided:

• Send a unique, time-limited token via email when users register
• Require users to click a link containing this token to verify their email
• Consider whether users should be able to use limited features before verification
• Implement a resend verification email feature for users who don’t receive the initial email

Email verification helps prevent account abuse, reduces spam registrations, and ensures you can contact users about important account information. Most authentication frameworks include built-in support for this workflow.

Two-Factor Authentication (2FA): When Extra Security Matters

Two-factor authentication significantly increases security by requiring something the user knows (password) and something the user has (typically a mobile device):

• Consider implementing 2FA for applications dealing with sensitive data or transactions
• Use established standards like TOTP (Time-based One-Time Password) for generating codes
• Offer backup methods (recovery codes) in case users lose access to their authentication device
• Clearly communicate the benefits of 2FA to encourage adoption

While 2FA adds complexity to your authentication system, it’s becoming increasingly important for applications handling sensitive information. Many frameworks now offer 2FA modules or integrations that simplify implementation.

When to Implement 2FA:

• Financial applications
• Healthcare or applications with sensitive personal data
• Administrative interfaces
• Enterprise applications
• Any application where security is paramount

Modern authentication frameworks often include built-in support for 2FA or have well-maintained extensions available, making implementation much simpler than building it from scratch.

Conclusion

Authentication is a critical component of your application’s security that’s easy to get wrong when building from scratch. By leveraging your framework’s built-in authentication solutions, you benefit from best practices refined by the security community over time.

Whether you choose social login, traditional password-based authentication, or a combination of both, focus on implementing these features using established, well-tested libraries. This approach will save you development time and help protect your users from common security vulnerabilities.

Remember that authentication is about building trust with your users. By implementing secure authentication practices, you demonstrate your commitment to protecting their data and accounts.

---

sources:

• https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/

In today’s digital landscape, the relationship between you and your users is built on a foundation of trust. When someone installs your app or signs up for your service, they’re not just evaluating your UI design or feature set—they’re making a decision about whether they can trust you with their data, their time, and sometimes their money. Security isn’t just a technical requirement; it’s a cornerstone of the relationship you’re building with your community.

Beyond the Green Lock: The True Meaning of Security

Many of us have been trained to look for the green padlock in our browser’s address bar as a sign that a website is “secure.” While HTTPS encryption is essential, that little green symbol doesn’t tell the whole story. A site can have perfect encryption for data in transit but still have vulnerable code, improperly stored user data, or outdated dependencies that put users at risk.

The padlock simply means the connection between the browser and server is encrypted—it doesn’t guarantee the site itself is secure against all threats. Some of the most devastating breaches have happened on sites with perfectly valid SSL certificates. True security goes much deeper than encryption alone.

The Fragility of Trust in the Digital Age

Trust takes time to build but can be shattered in an instant. When Buffer, the social media management platform, experienced a security breach in 2013, they took an unusual approach: radical transparency. They immediately notified users, provided continuous updates about what happened, and detailed the steps they were taking to fix the vulnerability. This approach helped them retain user trust despite the breach.

Not all companies are so fortunate. When Ashley Madison, a dating site, was breached in 2015, the particularly sensitive nature of the exposed data led to a mass exodus of users and irreparable brand damage. Some smaller apps and services have shut down entirely following security incidents, unable to recover from the loss of user trust.

The lesson is clear: for many users, a security breach isn’t just a technical problem—it’s a betrayal of trust that may lead them to permanently delete their accounts and warn others away from your service.

The Legal Aftermath of a Breach

Beyond the immediate trust implications, security breaches often come with legal consequences that many developers don’t anticipate:

• Notification Requirements: In many jurisdictions, you’re legally required to notify users of data breaches within a specific timeframe. The GDPR in Europe requires notification within 72 hours of discovery.
• Regulatory Investigations: Depending on the nature of your app and the data exposed, you might face investigations from data protection authorities, consumer protection agencies, or industry-specific regulators.
• Legal Liability: Users affected by breaches increasingly pursue legal action. Even small apps can face lawsuits if personal data is compromised.
• Compliance Penalties: Frameworks like GDPR can impose substantial penalties for security failures—up to 4% of annual global turnover or €20 million, whichever is higher.
• Ongoing Monitoring Requirements: After a breach, you may be required to implement specific security measures and undergo regular audits or monitoring.

For indie developers and small teams, managing these legal requirements while simultaneously addressing the technical aspects of a breach can be overwhelming, taking focus away from your core development work for months or even years.

Building Security on a Strong Foundation

The good news for vibe coders is that implementing basic security doesn’t have to be complicated or time-consuming. Modern development frameworks have evolved to include robust security features by default:

• Express.js has middleware like Helmet that sets security headers with one line of code
• React automatically escapes content to prevent XSS attacks
• Django (Python) includes protection against CSRF, XSS, SQL injection, and clickjacking out of the box
• Ruby on Rails implements security headers, CSRF protection, and SQL injection prevention by default
• Laravel (PHP) provides built-in protection against common vulnerabilities and easy encryption tools

These frameworks reflect decades of security lessons learned the hard way by earlier developers. By using them as intended and keeping them updated, you inherit substantial protection against common attacks.

Security as a Relationship Builder

When implemented thoughtfully, security can be more than just protection—it can be a feature that strengthens your relationship with users:

• Transparent Privacy Controls: When users can easily see and control what data you collect and how it’s used, it demonstrates respect for their autonomy.
• Visible Security Features: Two-factor authentication, login notifications, and session management give users tangible evidence that you care about their security.
• Proactive Communication: Notifying users about security updates and improvements shows ongoing commitment to protection.
• Security as Brand Value: Companies like Proton Mail and Signal have built their entire brand identities around security and privacy, turning what could be invisible technical details into key selling points.

The Long Game: Security and Sustainability

For vibe coders looking to build something lasting, security is an essential investment in your app’s future. Security incidents can derail momentum, drain financial resources, and divert creative energy toward crisis management rather than building cool new features.

Even more importantly, solid security practices protect the community you’re building. Whether you’re creating a game that brings friends together, a creative tool that empowers artists, or a social platform that connects like-minded individuals, your users are entrusting you with a piece of their digital lives. Honoring that trust through security best practices isn’t just technically sound—it’s the right thing to do.

By making security a priority from the beginning, you’re not just protecting code; you’re protecting relationships. And in the end, those relationships are what transform a cool project into a sustainable creation that can grow and thrive over time.

In this post I’ll show real life examples of security incidents and how to prevent them. They happen to a small, one person startups and big companies. Both

In the world of tech startups, speed often wins over everything. Teams focus on shipping new features, growing the user base, and impressing investors. Security? It’s often an afterthought—until something goes wrong.

Here are real examples of security incidents involving small web and mobile apps, and how they could’ve been prevented by embedding security practices early on.

Feeld Dating App – Sensitive User Data Exposure (2024)

Feeld, a UK-based dating app designed for people exploring alternative relationships, faced a serious security incident in 2024. Researchers discovered vulnerabilities that could’ve exposed private user data, including photos, messages, and sensitive relationship details.

Feeld fixed the issues within two months, but the situation highlighted how easily personal data could have been accessed.

How this could’ve been avoided:

• Implement proper authorization checks: Sensitive content should always be protected by strict access controls and verified user permissions.
• Conduct regular security audits and bug bounty programs: Feeld eventually committed to working with ethical hackers—this should’ve happened before the exposure.

Zapier – Code Repository Breach (2025)

Zapier, a well-known automation platform, experienced unauthorized access to its internal code repositories. Customer data unintentionally copied into debugging logs was potentially exposed. The breach occurred due to a misconfiguration of two-factor authentication (2FA) on an employee account.

How this could’ve been avoided:

• Enforce mandatory 2FA on all critical accounts: Especially for developer tools and admin access, 2FA should be non-optional and verified regularly.
• Avoid storing sensitive customer data in code repositories: Debug logs and development environments should never contain production user data.

Confidant Health – Therapy Session Data Exposure (2024)

A database belonging to Confidant Health, a telehealth startup, was left unsecured and publicly accessible. This leak exposed over 1.7 million activity logs and sensitive audio/video recordings of therapy sessions.

How this could’ve been avoided:

• Configure strict database access policies: Publicly accessible databases are almost always misconfigurations. Always apply IP restrictions, authentication, and network segmentation.
• Implement automated infrastructure security scans: Tools can continuously check for misconfigured storage buckets or databases.

MOVEit Software Breach – Massive Supply Chain Attack (2023)

While not a startup itself, the MOVEit breach affected thousands of organizations, many of them small startups using third-party software without reviewing its security posture. A vulnerability in MOVEit’s software enabled attackers to steal sensitive files via SQL injection.

How this could’ve been avoided (from a startup’s perspective):

• Assess third-party software risks: Startups should perform due diligence when integrating external platforms and regularly monitor vulnerability disclosures.
• Apply zero-trust principles and isolate critical systems: Even trusted third-party services should have minimal access to sensitive data.

SQL Injection

When user input isn’t properly sanitized before using it in database queries, attackers can inject malicious SQL commands. This can lead to unauthorized data access, complete database deletion, or even server compromise. In 2017, the Equifax breach exposed 147 million customers’ personal data due partly to SQL injection vulnerabilities. Even small apps aren’t immune—a local restaurant’s ordering system was compromised through SQL injection, leaking customers’ credit card information.

Cross-Site Scripting (XSS)

This occurs when your app displays unvalidated user input. Attackers inject malicious JavaScript that executes in other users’ browsers. In 2014, eBay had an XSS vulnerability that allowed attackers to create legitimate-looking listings containing malicious JavaScript. On a smaller scale, an indie game developer’s community forum was compromised when attackers injected scripts into profile descriptions that stole other users’ login credentials.

Broken Authentication

Flaws in login systems are extremely common in new applications. The 2018 Panera Bread website leak exposed millions of customer records because the site didn’t properly authenticate API requests for customer data. In another case, a small fitness tracking app had no brute force protection, allowing attackers to systematically guess passwords and access users’ health data and running routes.

Insecure Direct Object References (IDOR)

This happens when your app accesses objects based on user-supplied input without proper authorization checks. In 2021, a major dating app had an IDOR vulnerability that allowed accessing other users’ location data by simply changing ID numbers in API requests. A similar issue affected a portfolio site for photographers where changing the image ID in the URL revealed private commissioned work that wasn’t meant to be public.

Cross-Site Request Forgery (CSRF)

These attacks trick authenticated users into performing unwanted actions without their knowledge. In 2018, cryptocurrency exchange platform Coinbase patched a vulnerability that could have allowed attackers to drain users’ accounts through CSRF. A smaller example involved a self-published author’s website where an attacker created a malicious page that, when visited by the admin while logged in, changed book prices to $0.

Missing Rate Limiting

Without limits on how frequently actions can be performed, attackers can abuse your systems. In 2020, Zoom faced criticism for allowing unlimited password attempts without lockouts, enabling credential stuffing attacks. A small business’s appointment booking system was overwhelmed when a competitor used automated tools to book and immediately cancel hundreds of fake appointments, preventing legitimate customers from scheduling.

Exposed Secrets and API Keys

In 2024, researchers found over 3 million GitHub repositories leaking API keys and other secrets. The consequences are real: one indie game developer accidentally exposed their AWS keys in a public repository, resulting in cryptocurrency miners being deployed on their account, generating thousands of dollars in unexpected charges in just 24 hours.

Outdated Dependencies

The massive 2017 Equifax breach affected 147 million people and resulted from failing to patch a known vulnerability in Apache Struts. On a smaller scale, a local nonprofit’s donation page was compromised because it used an outdated version of a payment processing library with a known vulnerability, resulting in donations being redirected to fraudulent accounts.

Improper Error Handling

The 2019 Capital One breach exposed data of over 100 million customers partially due to misconfigured error handling that revealed too much information. A small e-commerce site for handmade goods unintentionally leaked customer shipping addresses through detailed error messages when order processing failed.

Lack of HTTPS

In 2017, all Starbucks user accounts were potentially exposed when their website failed to use HTTPS for login forms. A local music teacher’s student portal transmitted lesson recordings and payment information without encryption, allowing a malicious actor at the same coffee shop to intercept student data and payment details.

Remember, you don’t need to be a security expert to avoid these issues. Using modern frameworks with built-in protections, keeping dependencies updated, and following basic security practices will help keep your creative projects safe from the most common attacks.

When you’re creating something you love, whether it’s a cool web app, a mobile game, or a social platform, it’s natural to focus on making it work and look amazing. Adopting a security mindset means asking not just “How can I make this work?” but also “How could this break? How could someone misuse this?”

Combining Feature-First with Security-Aware

The security mindset starts with a simple realization: your application exists in a world where not everyone has good intentions. For every thousand users who love your creation, there might be one looking for weaknesses to exploit. These aren’t necessarily sophisticated hackers—often they’re just “curious” users who discover they can do something you didn’t intend, like accessing another user’s data by changing a URL parameter or bypassing a payment screen by manipulating browser requests.

But even users with good intentions may find security gaps or don’t even realize they access the information they shouldn’t. They may think that they found a cool new feature and it may be too late before you realize the damage they have accidentally done.

As a vibe coder, you might think, “My app is too small to be targeted.” But security incidents often happen to smaller apps precisely because they seem like easier targets. Your dating app, indie game, or portfolio site might not have millions of users, but a data breach could still harm real people who trusted you with their information. The security mindset means recognizing that the size of your project doesn’t diminish your responsibility to protect your users.

And it is much easier to introduce security features to a small app and let them grow with you although it may feel like a wasted effort. As I will try to show later it’s better to invest a small amount of time now then try to discuss high bills with your hosting provider or informing about data breach in your app later. Basic web app security isn’t really that hard!

Developing this mindset isn’t about becoming paranoid—it’s about being thoughtfully skeptical.

When you add a feature that lets users upload profile pictures, the creative part of your brain sees self-expression and community. But the security mindset asks: “Could someone upload malicious code instead of an image? Could large files crash my server? Could inappropriate content harm my community?” This isn’t negative thinking—it’s realistic preparation that makes your app more robust and trustworthy.

Secure Design Principles: Preventing Insecure Design

Insecure design has recently been recognized as one of the top application security risks (OWASP A04:2021). Unlike most vulnerabilities that happen during implementation, insecure design refers to flaws in the application’s architecture and design decisions that create security risks before a single line of code is written.

What is Insecure Design?

Insecure design happens when security isn’t considered from the beginning of creating a system. It’s like building a house without planning for locks on the doors or windows—no matter how well you construct it afterward, the fundamental design makes it vulnerable.

Key Secure Design Principles

Here are some essential secure design principles to incorporate into your thinking:

1. Defense in Depth – Never rely on a single security control. Layer your defenses so that if one fails, others still protect your application. For example, validate inputs on both client and server sides, and also sanitize data before using it in your database.
2. Principle of Least Privilege – Give users and system components only the minimum access they need to function. Your social media app’s photo uploader doesn’t need access to users’ private messages database.
3. Secure Defaults – Make the default configuration of your app secure. Users shouldn’t have to opt-in to privacy or security; they should be protected by default.
4. Fail Securely – When something goes wrong (and it will), ensure your system fails in a way that maintains security. For example, if authentication breaks, deny access rather than allowing everyone in.
5. Separation of Duties – Critical functions should require multiple people or components to complete. In financial apps, large transfers might need approval from a second user.

Simple Threat Modeling

One practical technique to apply secure design thinking is simple threat modeling. You don’t need complex methodologies—just ask these questions for each feature:

1. What are we building? – Sketch out the feature and its components.
2. What could go wrong? – Brainstorm ways it could be misused or broken.
3. What are we going to do about it? – Identify controls to mitigate each risk.
4. Did we do a good job? – Review after implementation.

For example, if you’re building a password reset feature:

• What are we building? A way for users to reset their password via email link
• What could go wrong? Attackers might guess or intercept reset tokens; users might use the feature for account enumeration
• What are we going to do about it? Use time-limited, single-use tokens; standardize responses regardless of whether an email exists
• Did we do a good job? Test the implementation against the identified risks

Learning from Others’ Mistakes

Some common insecure design patterns to avoid:

• Predictable resource locations – Using sequential IDs that allow enumeration (user/1, user/2, etc.)
• Relying on security through obscurity – Thinking that because a feature isn’t visible in the UI, it’s secure
• Assumption of trusted users – Designing as if all users will behave properly
• Lack of rate limiting – Not considering how features could be abused at scale

Real-world example: In 2019, a popular dating app had a design flaw where their “who likes you” feature could be reverse-engineered by analyzing network traffic patterns, even though the actual users were meant to be hidden behind a paywall. This wasn’t a code bug—it was a fundamental design flaw in how the feature was architected.

Starting Simple: Security by Design

The good news is that building security into your development process doesn’t have to be overwhelming. Think in terms of what is incoming to your app and what is returned. Start by questioning assumptions, thinking about potential misuse cases, and learning from others’ mistakes. The security mindset isn’t about knowing everything from day one—it’s about being willing to learn, adapt, and prioritize user protection as your creation grows from a personal project into something that matters to others.

Remember: It’s much easier (and cheaper) to design security in from the beginning than to retrofit it later. Even simple measures, like a 15-minute threat modeling session before starting a new feature, can save you countless hours of incident response later.