DEV Community: Uzair Saleem

Best Practices for Error Handling with async/await in JavaScript

Uzair Saleem — Thu, 14 Aug 2025 18:41:44 +0000

Error handling in async/await in JavaScript is crucial for building robust and reliable applications. While async/await makes asynchronous code look synchronous, you still need to actively manage potential errors. Let's dive into the best practices.

1. try...catch Blocks for Asynchronous Operations

This is the fundamental way to handle errors in async/await. Wrap the await calls that might throw an error within a try block, and handle the error in the catch block.


    async function fetchData() {
      try {
        const response = await fetch('https://api.example.com/data');

        // Always check response.ok for network requests!
        if (!response.ok) {
          // Handle non-2xx status codes by throwing an error
          throw new Error(`HTTP error! Status: ${response.status}`);
        }

        const data = await response.json();
        console.log('Data:', data);
      } catch (error) {
        // Catch any errors thrown in the try block (e.g., network issues, HTTP errors)
        console.error('Error fetching data:', error.message);
        // You might want to rethrow the error, display a message to the user, etc.
      }
    }

    fetchData();

2. Handle Errors at the Appropriate Level

Decide where an error should be caught and handled. Not every error needs to be handled at the lowest level. Sometimes, it's better to let an error propagate up the call stack until a more suitable level can deal with it (e.g., displaying an error message to the user, logging the error, or triggering a retry mechanism).

// Lower level function - lets errors propagate
    async function fetchUserPosts(userId) {
      const user = await getUser(userId); // This might throw an error (e.g., user not found)
      const posts = await getPostsForUser(user.id); // This might throw an error (e.g., no posts)
      return posts;
    }

    // Higher level function - handles the error from above
    async function displayUserContent(userId) {
      try {
        const posts = await fetchUserPosts(userId);
        renderPosts(posts);
      } catch (error) {
        console.error('Failed to display user content:', error.message);
        // Provide a user-friendly message
        showErrorMessageToUser('Could not load user content. Please try again.');
        // Optionally, log the full error details
        logErrorToService(error, { context: 'displayUserContent' });
      }
    }

3. Graceful Degradation and Fallbacks

When an error occurs, consider what a "good" fallback experience might be for the user. Instead of completely crashing or showing a generic error, can you:

Display cached data?
Show a skeleton loader with an error state?
Provide a retry button?
Disable a specific feature that relies on the failed operation?

async function loadProductDetails(productId) {
      try {
        const product = await fetchProduct(productId);
        renderProduct(product);
      } catch (error) {
        console.error('Error loading product:', error);
        // Graceful fallback: display a default message and a retry button
        renderErrorMessage(
          'Failed to load product details. Please try again.',
          () => loadProductDetails(productId)
        );
      }
    }

4. Custom Error Classes

For more complex applications, create custom error classes that extend Error. This allows you to differentiate between different types of errors and handle them more specifically.

class NetworkError extends Error {
      constructor(message) {
        super(message);
        this.name = 'NetworkError';
      }
    }

    class ValidationError extends Error {
      constructor(message, details) {
        super(message);
        this.name = 'ValidationError';
        this.details = details; // Specific validation details
      }
    }

    async function submitForm(data) {
      try {
        const response = await fetch('/api/submit', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify(data),
        });

        if (!response.ok) {
          if (response.status === 400) {
            const errors = await response.json();
            throw new ValidationError('Invalid form data', errors.errors);
          } else if (response.status >= 500) {
            throw new NetworkError(`Server error (${response.status}) submitting form`);
          } else {
            // Catch any other non-2xx status codes
            throw new Error(`Unexpected HTTP error: ${response.status}`);
          }
        }
        return await response.json();
      } catch (error) {
        if (error instanceof ValidationError) {
          console.warn('Validation failed:', error.details);
          // Display specific validation messages to the user (e.g., next to input fields)
          displayFormValidationErrors(error.details);
        } else if (error instanceof NetworkError) {
          console.error('Network error:', error.message);
          // Inform the user about network issues
          showToast('Connection issue. Please check your internet.');
        } else {
          console.error('An unexpected error occurred:', error);
          showGenericErrorMessage();
        }
      }
    }

5. Centralized Error Logging

For production applications, don't just console.error. Send errors to a centralized logging service (e.g., Sentry, Bugsnag, Datadog, ELK stack, cloud logging services). This helps you monitor your application's health and identify issues proactively.

// A simple logger abstraction
    const AppLogger = {
      error(error, context = {}) {
        console.error('Application Error:', error, context);
        // In a real app, send this to a service like Sentry or Bugsnag
        // Sentry.captureException(error, { extra: context });
      },
      info(message, context = {}) {
        console.log(message, context);
      },
    };

    async function performImportantTask() {
      try {
        await someRiskyOperation();
        AppLogger.info('Important task completed successfully.');
      } catch (error) {
        AppLogger.error(error, { task: 'ImportantTask', userId: 'xyz' });
        // User-facing message
        showErrorMessageToUser('Something went wrong. We have been notified of the issue.');
      }
    }

6. Using finally for Cleanup

The finally block ensures that certain code runs regardless of whether an error occurred or not. This is incredibly useful for cleanup tasks like closing connections, releasing resources, or hiding loading spinners.

async function uploadFile(file) {
      showLoadingSpinner(); // Show spinner before starting

      try {
        const response = await fetch('/upload', {
          method: 'POST',
          body: file,
        });
        if (!response.ok) {
          throw new Error('Upload failed');
        }
        console.log('File uploaded successfully');
        showSuccessMessage('File uploaded!');
      } catch (error) {
        console.error('Upload error:', error.message);
        showErrorMessageToUser('File upload failed. Please try again.');
      } finally {
        hideLoadingSpinner(); // Always hide spinner, success or failure
      }
    }

7. Avoid Swallowing Errors

Don't just catch an error and do nothing. This is known as "swallowing" an error and makes debugging incredibly difficult because the error vanishes without a trace. If you catch an error, either handle it meaningfully (e.g., display to user, log it) or rethrow it (or a new, more specific error) to propagate it up the call stack.

Bad Practice (Don't do this!):

async function doSomethingBad() {
      try {
        await someFailingOperation();
      } catch (error) {
        // Doing nothing with the error - BAD!
        // The error is gone, and you'll never know it happened.
      }
    }

Good Practice (Handle or rethrow):

async function processData() {
      try {
        const data = await fetchDataFromAPI();
        return processAndValidate(data);
      } catch (error) {
        console.error('Error in processData:', error);
        throw new Error('Failed to process data due to API error.'); // Rethrow a more generic error
      }
    }

8. Promise-based Error Handling (for unawaited promises)

If you have promises that are not awaited, you must use .catch() for their error handling, as try...catch will not intercept errors from unawaited promises in the same scope. This is a common pitfall!

async function demoUnawaitedPromiseError() {
      try {
        // This promise is not awaited. Its rejection will NOT be caught here.
        new Promise((resolve, reject) => {
          setTimeout(() => reject(new Error('Uncaught promise error!')), 100);
        });
        console.log('This will still print, but the promise error is unhandled by this try...catch.');
      } catch (error) {
        // This catch block will NOT execute for the unawaited promise above.
        console.error('This try...catch will NOT catch the promise error.');
      }
    }

    demoUnawaitedPromiseError();

    // Correct way to handle errors in unawaited promises:
    function anotherDemo() {
      new Promise((resolve, reject) => {
        setTimeout(() => reject(new Error('Handled promise error via .catch()!')), 100);
      })
        .then((data) => console.log('Promise resolved:', data))
        .catch((error) => {
          console.error('Caught with .catch():', error.message);
        });
    }
    anotherDemo();

9. Global Unhandled Promise Rejection Handling

For unforeseen errors from unhandled promise rejections (which are often from promises not awaited or explicitly .catch()ed), you can set up global handlers. These are a last resort for catching bugs you might have missed.

Node.js:

process.on('unhandledRejection', (reason, promise) => {
      console.error('Unhandled Rejection at:', promise, 'reason:', reason);
      // Log this to your logging service (Sentry, etc.)
      // Sentry.captureException(reason);
      // Depending on the severity, you might want to exit the process:
      // process.exit(1);
    });

Browsers:

window.addEventListener('unhandledrejection', (event) => {
      console.error('Unhandled Rejection (Browser):', event.reason);
      // event.reason holds the error object
      // Log event.reason to your logging service
      // Sentry.captureException(event.reason);
      // Prevent default handling if you're taking over
      // event.preventDefault();
    });

While useful for catching last-resort issues, relying heavily on global handlers is generally a sign that specific try...catch or .catch() blocks are missing in your application logic. Always strive for explicit error handling.

By consistently applying these best practices, you can build more resilient, maintainable, and user-friendly applications with async/await. Happy coding!

How the Tea App Got Hacked: Firebase Pitfalls and Lessons for Engineers

Uzair Saleem — Sat, 02 Aug 2025 15:11:48 +0000

Tea, a dating platform for women – recently became a symbol of security failure when misconfigured Firebase backends left thousands of private records exposed.

The recent Tea app breach wasn’t some esoteric exploit; it was a textbook case of bad architecture and misused Firebase services. In fact, security analysts noted this was “not a sophisticated hack; it was an unlocked front door”, it had nothing to do with “vibe coding” or AI – it was due to “horrible design decisions” like treating Firestore/Storage as an open-ended backend and skipping basic security rules

I’ll show you exactly what went wrong, from the open Firebase Storage bucket to the broken access controls in the chat API, and how client-side-only checks magnified the problem. I’ll show code/config examples of insecure vs secure Firebase rules, explain why you almost always need a proper server/API layer, and offer concrete takeaways so you never repeat Tea’s mistakes.

The dev team at tea treated Firebase like an instant backend platform but never implemented real security controls.

Firebase-as-DB without safeguards: By relying on Firestore/RealtimeDB and Storage directly from the client, Tea effectively let the frontend talk straight to the data. Any logic in the app (like “only show your own chats”) meant nothing if the database rules weren’t locked down. Security pundits note that connecting users directly to the database is risky, this is why we have the best practices in NEXT.js to use the Data Access Layer and add proper checks for the user authenticated state.
Tea simply left those controls wide open.

Legacy data left unprotected: The company admitted that a “legacy data” store (pre-Feb 2024) was never migrated or secured. That old Firebase bucket contained ID photos and comments. It should have been locked or deleted, but instead became a gaping hole. Outdated systems were left accessible with no oversight.

Security should’ve been part of “Done”: The Tea app was a runaway success (millions of users) built by a small team. In the rush, they seemingly skipped security audits. As one commentator notes, a single script checking Firebase permissions would have prevented the disaster.

What I learned is design your system with security by default, not as an afterthought.

Together, these points highlight how misusing Firebase/Firestore as an open backend – especially with default/test rules – let attackers walk right in.

Let’s break down the specific flaws that were exploited:
Public Firebase Storage Bucket – No Authentication: Tea stored user IDs, selfies, and images in a Google Firebase Storage bucket that required no auth tokens. In other words, anyone with the URL could list or download files.

Broken Access Controls(Exposed All chats): Separate from the images, Tea’s chat data ended up in another Firebase database (Firestore or RealtimeDB). Here too, the rules were botched. A researcher found that any authenticated user (with Tea’s API key built into the app) could query all chat messages – not just their own. In other words, the app had an Insecure Direct Object Reference: you could just ask for messages by ID or even listen to a whole collection. As detailed in a post-mortem, attackers discovered “an open Firestore or real-time database instance with 1.1 million private chat messages”, all readable with a standard API key

This is a classic broken access control: there was no server-side check enforcing “you can only read your own messages”. Instead, the client controlled nothing. With the leaked database keys or API key, anyone could pull everyone’s DMs.

Secrets in the Client – Keys and endpoints exposed: Compounding the above, Tea had placed critical information in the mobile app code itself. The Firebase project keys were visible in the app’s code, and the admin panel URL was public with no rate-limiting

Tea’s clients effectively had the skeleton key to their own database built in, so once the bucket was public and the rules wide open, the attackers had unrestricted access.

Client-side Security Checks – No server enforcement: Because the design leaned on Firebase, any access control was done (if at all) on the front-end. For example, the app might show or hide UI buttons, or check chat IDs in JavaScript. But with direct DB access, none of that mattered.

In Tea’s case, the app may have been “invite-only” or checked a user’s gender on the client, but the backend had no rule enforcing the same. This is a huge red flag, if your security depends on code running in the user’s browser or phone, it’s usually broken. All critical checks belong on a trusted backend.

In summary, the root technical failures were leaving Firebase services unlocked and trusting the client. The result, thousands of sensitive images and messages spilled out without a fight.

Insecure vs Secure Firebase Rules
A concrete way to understand Tea’s mistake is to compare insecure and secure Firebase rules. For example, an open Storage bucket rule in Firebase might look like this:

service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { // This allows anyone to read or write ANY file allow read, write; } } }

This is essentially “test mode” – it grants worldwide read/write access with no checks. It’s equivalent to Google Drive’s “Anyone with link Reader”. Tea’s Storage bucket almost certainly had an override like this, or was left in default test mode

In contrast, a secure rule locks things down by requiring authentication and matching data paths. For example, if each user’s uploads were under user_uploads/{userId}/…, a better rule would be:

service firebase.storage { match /b/{bucket}/o { // Files under user_uploads must belong to the authenticated user. match /user_uploads/{userId}/{fileName} { allow read, write: if request.auth != null && request.auth.uid == userId; } } }
Here, request.auth.uid is the logged-in user’s ID. We only allow access if it matches the {userId} folder. No authentication = no access. In this model, Alice can only read/write files in her own folder. Likewise, for Firestore/RealtimeDB data, you would avoid allow read, write: if true (which ignores auth) and instead write rules like:

{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", // each user read their own node ".write": "$uid === auth.uid" } } } }

Such rules force the database to enforce user identity

A secure rule always checks request.auth != null and other conditions before allowing access. Always review your Firebase security rules — they are your last line of defense!
Why a Proper API Layer Matters
The Tea hack also highlights why relying on Firebase alone can be dangerous. In a classic server-based app, all data access goes through your own API, which enforces auth, roles, quotas, and logs every action. With Firebase, you gave up that layer and expected the database to gatekeep. That means your only security controls were the Firebase rules (and Google Cloud IAM) – and Tea’s were off. This is a big architectural gamble, modern tools like Firebase “encourage just that” (direct DB connections), meaning “apps implement detailed access control rules, but they become meaningless once the user connects directly to the database”

In Tea’s case, there was no intermediate server to log access, validate complex policies, or throttle abuse. If Tea had built a standard backend API (e.g. a Node/Express, Golang service) they could have implemented server-side access controls for chats and files, used middleware for authentication, and kept audit logs of every query. Even if someone leaked a database key, the backend could have rate-limited requests or blocked suspicious patterns. Instead, the Firebase “API” key in the client was all the attacker needed, and no central logic was there to intervene. In short: don’t treat Firebase like a drop-in replacement for your server. Use Cloud Firestore or Realtime DB as a supplement, not a substitute. For any serious app, still run a trusted server layer or cloud functions that validates who’s doing what. That way, even if a user manipulates the client, the server enforces the rules.

Lessons I Learned:

What practical steps should you take after reading about Tea?
Lock Down Your Database – Never leave a Firebase bucket or collection open. In testing, rules may allow public access, but before launch change them. Always require request.auth checks. Audit your rules early and often
Many cloud providers and CI tools can automatically scan for “allow if true” patterns or public S3/Firebase buckets and warn you.

Keep Secrets Secret – Don’t embed API keys or secrets in your mobile/JS code. Instead, restrict each key’s privileges. Tea’s keys were in the client, which let hackers use them freely. Put sensitive logic on the server and use secure channels for any keys.
Harden Admin Interfaces – Any web dashboard or admin portal should be behind strong auth. Add multi-factor auth (MFA) and rate-limit login attempts. Tea’s admin panel had no rate limiting, making brute force easy

MFA and IP whitelisting for admin login would block most attacks.
Delete What You Don’t Need – If you ask users for photos or IDs, have a clear retention policy. Don’t hoard old verification pictures in a “legacy” storage just because you think you might need them. Tea claimed “selfies were not deleted as expected,” violating their policy
Shred data as soon as it serves its purpose, especially sensitive PII.

Test from the Outside – Think like an attacker. Can you access your resources without logging in? Try connecting a generic Firestore client with your Firebase project ID to see if it bypasses auth.
Use automated tools (DAST scanners, Firebase rule simulators) as part of your pipeline.

Implement Monitoring & Alerts – In a DevOps mindset, monitor your cloud config. Tools like Google Cloud Asset Inventory or third-party config scanners can alert you if a bucket suddenly becomes public.

Likewise, watch for unusual API usage patterns. If Tea had config monitoring, the open bucket might have been flagged immediately.

Cultural and Organizational Takeaways

Beyond code, the Tea breach underscores a cultural pitfall, speed without guardrails. As one security expert notes, the Tea hack exemplifies how “speed, intuition, and improvisation” (“vibe coding”) lead to “fragile systems” and “catastrophic security failures”

This is crucial: when a project lacks code reviews or security specialists (common in small startups), easy mistakes slip through. Tea apparently left a legacy system running without anyone auditing it – a governance failure.

Finally, think like defenders: Had Tea’s DevOps pipeline run a Firebase rules scan or someone launched a quick penetration test, the open storage would’ve been caught. Automated code analysis (SAST) might not flag config, but cloud config scanners, IaC checks, and even simple automated scripts (as analysts pointed out) would have found “allow read, write” rules before release.

Conclusion
The Tea app hack was brutal and deeply avoidable. From open Firebase buckets to missing access checks, the vulnerabilities were the kind any diligent engineer could prevent. The moral: never deploy user data storage on autopilot. Always assume “if it’s possible, it will be done” by attackers – and write your rules accordingly. Use proper server-side auth where needed, lock down cloud storage, automate your security checks, and maintain a skeptic’s mindset about any “easy” cloud backend shortcut. By applying these lessons, developers can build consumer apps that truly respect privacy and security – preventing a repeat of Tea’s unfortunate lesson on the internet.

Treat backend-as-a-service with caution – always write tight security rules. Keep secrets off the client. Use proper APIs to enforce access. Automate scans and reviews in your pipeline. And never let “we’ll fix it later” creep into production code. Users trust you with their data; earning that trust requires diligence at every layer.
Keep coding.