DEV Community: Hassam Fathe Muhammad

[Boost]

Hassam Fathe Muhammad — Tue, 04 Aug 2026 19:05:47 +0000

Hassam Fathe Muhammad

Aug 4

Building a Secure WebSocket-Based Customer Support Chat: Chat Policies, Rate Limiting, and BOLA Prevention

#websocket #cybersecurity #node #typescript

3 min read

Building a Secure WebSocket-Based Customer Support Chat: Chat Policies, Rate Limiting, and BOLA Prevention

Hassam Fathe Muhammad — Tue, 04 Aug 2026 10:50:06 +0000

Being a full-stack developer for quite some time, I have been consistently upgrading my full-stack knowledge by learning new technologies and features, along with how to implement them in a secure way.

What are WebSockets?

WebSockets provide a full-duplex, persistent communication channel between the client and the server, enabling real-time data exchange without repeatedly creating new HTTP requests. They are widely used in applications such as chat systems, live notifications, collaborative platforms, and online gaming where low-latency communication is essential.

Implementing a Customer Support Chat System

This time, I learned and implemented WebSockets for a customer service chat system, and I used the concept of a Chat Policy for blocking customer-to-customer chats, which is against the policy of a customer service chat system where only admins and agents are allowed to be texted.

On top of this, I learned how to implement a Chat Policy Service, a completely distinct service with its own database queries and validations, and then integrate it into the message-handling events. You can create your own chat policy based on a specific database schema according to your application's requirements.

Project Architecture

The overall folder structure of the chat system was organized by separating the socket initialization, socket events, services, middleware, authentication, and utilities, making the architecture modular and easier to maintain.

The message handling logic remained inside dedicated event handlers, while business logic such as Chat Policy validation was delegated to its own service, following the principle of Separation of Concerns (SoC).

Example Folder Structure

src/
├── socket/
│   ├── initSocket.ts
│   ├── onlineUsers.ts
│   ├── events/
│   │   ├── messageHandler.ts
│   │   └── disconnectHandler.ts
│   └── middleware/
│       └── socketAuth.ts
├── services/
│   ├── chatPolicy.service.ts
│   └── message.service.ts
├── models/
├── routes/
├── types/
├── utils/
└── server.ts

Implementing Rate Limiting

Along with this, I also came to understand the importance of rate limiting while sending text messages, so I learned to implement rate limiting using JavaScript's Map.

One thing that could be useful for your knowledge is creating a single instance of the service and exporting it. This allows all event handlers to use the same Map across requests; otherwise, the counts and user information would not remain synchronized because each new instance would maintain its own separate memory.

This approach works well when running a single server instance and is unlikely to restart or crash frequently. However, because Map stores data only in memory, it is not persistent and does not work across multiple server instances. A more professional and production-standard solution is Redis, which provides centralized and persistent storage shared among all application instances.

Map-Based Rate Limiter

import { UserLimit } from "../types/rateLimit.types.ts";

class RateLimiter {

    private users = new Map<string, UserLimit>();

    private readonly MAX_MESSAGES = Number(process.env.RATE_LIMIT_MESSAGES) || 5;
    private readonly WINDOW_MS = Number(process.env.RATE_LIMIT_WINDOW) || 1000;

    public canSend(username: string): boolean {
        const now = Date.now();
        const user = this.users.get(username);

        if (!user) {
            this.users.set(username, {
                count: 1,
                windowStart: now
            });
            return true;
        }

        if (now - user.windowStart > this.WINDOW_MS) {
            user.count = 1;
            user.windowStart = now;
            return true;
        }

        if (user.count > this.MAX_MESSAGES) {
            return false;
        }

        user.count++;
        return true;
    }
}

export default new RateLimiter();

Preventing Broken Object Level Authorization (BOLA)

In addition to these security standards, one more important thing that I implemented was preventing the flaw of Broken Object Level Authorization (BOLA), which is one of the most critical API security vulnerabilities.

BOLA occurs when an application trusts object identifiers or user information received from the client without verifying whether the authenticated user is actually authorized to access or modify those resources. A secure implementation should never trust identifiers such as usernames or user IDs coming directly from the frontend.

While implementing the chat system, I learned to extract the authenticated user's ID and username directly from the verified authentication token instead of accepting them from the client payload. This ensures that every authorization decision is based on the identity established by the server after token verification, preventing malicious users from impersonating other users simply by modifying request data.

By performing authorization checks on the server and validating permissions before processing chat events, the system effectively mitigates the risk of BOLA and enforces secure access control throughout the messaging workflow.

Key Takeaways

Learned to build real-time communication using WebSockets.
Implemented a dedicated Chat Policy Service for authorization rules.
Structured the application using Separation of Concerns (SoC).
Implemented Map-based rate limiting and understood its limitations.
Learned why Redis is the production-standard solution for distributed rate limiting.
Prevented Broken Object Level Authorization (BOLA) by extracting authenticated user information from verified tokens instead of trusting client-provided data.
Improved my understanding of secure backend architecture and real-time application development.

How to Recover Lost Email IDs, Usernames, or Account Info Using Chrome/Browser Dev Tools

Hassam Fathe Muhammad — Tue, 16 Jun 2026 17:28:12 +0000

Mostly, if someone forgets account information, it is usually the password, and less commonly the username or email. But sometimes this can happen to many people working in tech due to handling multiple versatile accounts across different websites for relatively specific work.

For example, on a hosting platform or database platform, one can have two accounts — one for personal experiments and one for production or professional work.

In my case, I similarly had two accounts on a platform, and the Gmail ID used for one of them was very rarely used and not very active, due to which I forgot it completely. I also had no Google session logged in through which I could get the idea of the Gmail ID.

After a long time, the platform refreshed its session and required a new login, with no account suggestions available. Now I was trapped with no idea of the Gmail ID.

Neither the CLI of that platform was giving me my Gmail ID, nor any other command, etc. Since the email was the main identifier, the CLI was not revealing it. This could be due to several reasons:

Either it had no such function,
It was never required before,
Or the command was never commonly used, making it difficult even for ChatGPT or other AI assistants to provide a solution.

At this point, I used my development knowledge and anticipated that most web apps use cookies and browser storage to store user or session-related information.

So, I went to the platform site, opened Inspect/Developer Tools, and checked:

Application → Cookies
Local Storage
Session Storage

There, I found the same Gmail ID that I had used on the platform, allowing me to proceed and regain control of the account.

The purpose of sharing this troubleshooting method is to help contribute toward recovering lost account information using one's own device and one's own browser inspect tools.

However, such techniques and knowledge should never be used to copy, steal, or misuse someone else's session or account information from their devices.

[Boost]

Hassam Fathe Muhammad — Fri, 15 May 2026 09:23:27 +0000

Hassam Fathe Muhammad

May 14

Beyond CRUD: Building Scalable Backends with Work Queues and Job Processing

#backend #systemdesign #node #bullmq

4 min read

4 Tiny Frontend Mistakes Quietly Killing Your App Performance

Hassam Fathe Muhammad — Thu, 14 May 2026 19:09:25 +0000

Real-world cases and energy-saving impacts

Sylwia Laskowska

May 14

4 Tiny Mistakes That Secretly Destroy App Performance

#javascript #angular #react #frontend

112

6 min read

Beyond CRUD: Building Scalable Backends with Work Queues and Job Processing

Hassam Fathe Muhammad — Thu, 14 May 2026 18:27:37 +0000

Apart from CRUD work in backend, there is a lot more to learn and implement in your projects to allow scalable, powerful, and reliable system design. As most of us full-stack and backend developers work with APIs for user-oriented operations which are being triggered from frontend by end users in their various tasks, and then the response of those APIs for that task informs user and drives their work forward, navigates them to further pages, fetches them the required info, and provides them with services.

But not all types of workflows can be given to a designed API and then accomplished in short time with that one single API — it can be, but not on user's waiting. The user expects the web app or app response for his or her simple triggered task. But it is the backend which knows how many actions and tasks must be performed and in which order.

The Solution: Work Queues

For this we use Work Queues and give the work to the workers, whereas a success or work-in-progress response is being sent to the user — allowing it to move along rather than waiting for the whole set of backend operations.

My Implementation Journey

For explanation and demonstration, I will be implementing this concept in one of my projects which involves a set of tasks. As I also worked with Redux for state management in my 'Nur Fashions' e-commerce web app, I decided further upgrade of this project with queues & jobs would be better for learning and productive for this project, adding value to it.

Technology Stack

The module/library I used for this was BullMQ and the storage and execution engine used was Redis, as BullMQ is made on top of Redis. So I used Docker to run my Redis image and allow connection from localhost.

Use Case: Order Processing

Now in my Nur Fashions e-com web app, I selected the order processing aspect. As the backend was already saving order entry to the database and giving success response, now as we discussed, we did not need to overwhelm this API and add other required tasks into it such as:

Update Inventory for selected ordered items
Send Email to customer (user)
Generate Invoice

which I now gave to the workers of the queue.

System Architecture & Design

Now as I always try to design systems for scalability and modular for cleaner and helpful abstraction, so I made up:

Queue Config File

Job Addition From Controller Code:

await orderQueue.add("processOrder", {
    orderId: orderData.orderId,
    orderEmail: orderDetails.customer.email,
    items: orderDetails.items
}, {
    attempts: 5,
    backoff: {
        type: "exponential",
        delay: 5000
    },
    removeOnComplete: 100,
    removeOnFail: false,
});

Worker Task Handling File along with limiter and retry logic

Running Workers Separately

Now it was observed and learned by me that workers and queues must be started separately. So as this was a crucial part of server/backend, I used a module called 'concurrently' which executes a list of commands at the same time.

So I made up one index.ts main worker file which was importing Order Worker File, allowing to start different workers in future.

Handling Job Failures: The Critical Part

This is where I got this concern of what if any task/job fails. So I got confronted by different approaches in which the more obvious all along was to have a vast and detailed DB schema for order table/collection. So I made up properties/attributes such as:

inventoryProcessed: Boolean,
inventoryProcessedAt: Date,
emailSent: Boolean,
emailSentAt: Date,
invoiceGenerated: Boolean,
invoiceGeneratedAt: Date,
processing: {
    inventoryError: String,
    inventoryLastAttempt: Date,
    emailError: String,
    emailLastAttempt: Date,
    invoiceError: String,
    invoiceLastAttempt: Date
}

Dual Storage Strategy

This allowed me to update info for dead jobs handling and debugging. Along with this, I used Redis to store flags based on completion/failure of jobs:

try {
    const inventoryProcessed = await redis.hget(`order:${orderId}:flags`, "inventoryProcessed");

    if (inventoryProcessed !== "1") {
        console.log("Updating Inventory: ", orderId);
        await InventoryController.updateInventoryPostOrder(items);

        await Promise.all([
            await redis.hset(`order:${orderId}:flags`, "inventoryProcessed", "1"),
            await order.updateOne({orderId}, {
                inventoryProcessed: true, 
                inventoryProcessedAt: new Date()
            })
        ]);     
    } else {
        console.log("Inventory Already Processed, ", orderId);
    }
} catch (error: any) {
    errors.inventory = error.message;
    console.log(`Error While Updating Inventory, ${orderId}, `, error.message);

    await order.updateOne({orderId}, {
        "processing.inventoryError": error.message,
        "processing.inventoryLastAttempt": new Date()
    });
}

As in the same way for other tasks in this order process.

Then I also configured the limiter as down below and did exception/error handling along notifying the admin for failed jobs:

{
    connection: { host: "127.0.0.1", port: 6379 },
    limiter: {
        max: 10,
        duration: 10000,
    },
    concurrency: 5
}

///////////

worker.on("completed", (job) => {
    console.log(`Job ${job.id} completed Successfully`);
});

worker.on("failed", async (job, error) => {
    console.error(`Job ${job?.id} failed, `, error.message);

    if (job && job.attemptsMade >= 3) {
        await AlertController.sendAlertToAdmin({
            orderId: job.data.orderId,
            error: error.message,
            attempts: job.attemptsMade
        });
    }
});

worker.on("error", (error) => {
    console.error("Worker Error, ", error);
});

Conclusion

Now this is how I learned and implemented worker queues using BullMQ to add scalable, value, and reliable features to my backend, upgrading my backend skill stack and keeping users moving along on the frontend.

Real engineers:

Design for scale from the start
Handle failures gracefully
Keep users informed without making them wait

[Boost]

Hassam Fathe Muhammad — Sat, 28 Mar 2026 09:27:44 +0000

klement Gunndu

Mar 25

Vibe Coding Got You Started. These 5 Skills Keep You Employed.

#ai #beginners #career #programming

6 min read

Just Did Work On OWASP A05

Hassam Fathe Muhammad — Fri, 27 Mar 2026 15:23:12 +0000

Hassam Fathe Muhammad

Mar 27

OWASP Top 10 – A05: Security Misconfiguration (Remediation Perspective)

#security #systemdesign #owasp

3 min read

OWASP Top 10 – A05: Security Misconfiguration (Remediation Perspective)

Hassam Fathe Muhammad — Fri, 27 Mar 2026 15:22:40 +0000

As I have been working with OWASP Top 10, so far I have studied A01 to A04 and performed remediations according to them on my projects, so I can have an idea of security and standard testing of my web apps. In this article, I would like to tell you about my work regarding A05, which is Security Misconfiguration.

t is observed by me that many of the aspects addressed in one OWASP category can also be addressed in more than one category. So this is more about discipline while developing a web app.

In my work on OWASP A05, I performed the following remediations and improvements:

Note: As some aspects are also addressed in more than one OWASP category, my work is more likely inclined toward one specific category in this article.

Environment Configuration

One of the aspects that many beginner developers miss out on—and exhibit work-shyness in—is not preparing separate environments for:

Development (Project Making)
Local (Running on a local closed network)
Production (Deploying the project as delivered and ready to meet the internet)

This configuration can be done by preparing .env files accordingly and editing them for the type of project start.

**For example: **It is best and advised to have this variable:

NODE_ENV=production

The variable value can be changed according to the project environment like "dev" for development, "local" for local, and "prod" for production.

This allows necessary condition checks and flag triggering such as:

if (process.env.NODE_ENV === "production") {
  app.set("trust proxy", 1);
}

This allows IP address logging and other rate-limiting and security methods to be applied.

Note: Proxy must be trusted with this flag only if you are using NGINX or another trusted reverse proxy like Cloudflare or reputed hosting services.

Secure HTTP Headers

Another security misconfiguration that must be handled is the use of Helmet for securing HTTP headers.

import helmet from "helmet";

app.use(helmet());

This adds:

Content-Security-Policy
XSS Protection
Frameguard
HSTS

CORS Configuration

Another important configuration is CORS:

app.use(cors({
  origin: ["https://yourfrontend.com"],
  credentials: true
}));

One should regularly identify their domains and use the correct URLs in their CORS configuration.

Hide Sensitive Errors

Many developers forward backend errors to the frontend for quick debugging, like:

res.status(500).json({ error: err });

This is not advised, as it may expose backend structure, repositories, or system limitations.

Instead, use standard messages such as:

res.status(500).json({ message: "Internal Server Error" });

For debugging, use server logs:

try {
  // Logic
} catch (error) {
  console.error("Error While Processing In (Endpoint)", error);
  res.status(500).json({ message: "Internal Server Error" });
}

Disable Stack Traces & Info Leaks

Information about backend resources matters a lot. It allows attackers to guess weaknesses and evaluate your servers.

We can use:

app.disable("x-powered-by");

This hides:

X-Powered-By: Express

Enforce HTTPS

When using hosting services, they often handle HTTPS automatically.

But when deploying manually using a reverse proxy like NGINX, ensure:

NGINX + Certbot setup
Redirect HTTP → HTTPS
Install SSL certificate

Usually, this is part of NGINX deployment.

Secure Cookies

While setting cookies from the backend, ensure the following:

res.cookie("token", token, {
  httpOnly: true,
  secure: true,
  sameSite: "strict"
});

Remove Default Credentials

During development, many developers use default credentials for quick testing.

Removing these from the database is very important.

If missed, attackers might try:

Username: admin
Password: admin

and gain admin access.

Advanced Insight

Security Misconfiguration is NOT a bug. It’s a discipline problem.

Most developers:

Focus on features
Ignore deployment & configurations

Real engineers:

Secure systems at both infrastructure and application levels

Redux vs React Context: A Practical Perspective from a Real Project

Hassam Fathe Muhammad — Wed, 28 Jan 2026 16:39:55 +0000

Back then, I started using React Context in my web apps mainly for auth and session-related info/status.

The idea of Context is simple: it is created for the app (its components) so that prop drilling can be avoided, and the state can be easily accessed by the components that actually need it—while ensuring proper updates and usage of state data.

The React Context API (createContext, useContext, useState, etc.) worked well for me, and I’ve used it in many of my web apps (React + Next.js).

What I liked the most—and what I think many developers will find helpful—is how it eliminates prop drilling and helps in understanding the layout structure when using a Context Provider. I became quite comfortable with React Context.

But there is also another library designed for managing shared state and complexity: Redux.

Enter Redux

Using Redux requires understanding a few core concepts:

Store
Slices
Reducers
Actions

The Store, which is the global state container, is singular—there is only one store in an app. Inside it, you have multiple slices, where each slice represents a specific feature or concern and contains its state, reducers, and actions.

I’m not writing this article to teach Redux or deeply explore its internal structure. Instead, I’ll explain my thinking using an example from one of my projects.

A Real Project Example

I have an e-commerce-based Next.js web app called Nur Fashions. It’s a template-nature, client-based project.

In this project, I’m using React Context for:

Authentication
Cart management
Location (for currency, etc.) From my experience, Context API is completely fine for these use cases.

Why?

No complex backend involvement
No heavy backend syncing
No asynchronous workflows
Fewer uncertain or branching operations

So for these parts of the app, React Context is more than enough—there is simply no need for Redux here.

Where Redux Makes Sense

However, one important process in this app is the ordering flow after cart checkout.

This process needs to be handled very carefully:

It involves asynchronous operations with the backend
It requires clearly defined and strongly typed states (loading, success, failure, etc.)
It has the potential to grow in complexity and scalability, with more backend syncing and business logic added over time

For this reason, using Redux here felt both reasonable and professional. So I set up Redux (store + slice) and wrapped it with a provider in the layout.

A Key Realization

While working on this, I came across a very important professional insight:

Redux is NOT about lifetime. Redux is about complexity.

Before understanding this, I was more convinced of the idea that Redux should only be used for long-living context or global state. But now my perspective has changed.

What truly matters is how complex and scalable the state logic is, not how long the data lives.

And that, for me, is the real distinction between React Context and Redux.

OWASP Top 10 – A04: Insecure Design (Remediation Perspective)

Hassam Fathe Muhammad — Wed, 28 Jan 2026 15:54:00 +0000

As I have been trying to cover the OWASP Top 10 to make my full-stack development skills more valuable, standardized, and aligned with the cybersecurity domain, the topics I have already covered include:

A01 – Broken Access Control
A02 – Cryptographic Failures
A03 – Injection

In this article, I will talk about A04 (Insecure Design), its remediation, and how it differs from A01 in some important ways.

What A04 (Insecure Design) Focuses On

A04 focuses on the absence of proper logic and security mechanisms at the design and implementation level of a web application or website, which ultimately makes it insecure.

Some practices that commonly lead to Insecure Design include:

Trusting the client-side too much
Not designing APIs and gateways according to server-issued protocols and rules
Performing sensitive processing on the client side
Fetching sensitive data on the frontend when it is not required

Practical Handling of A04 in My Project

In this article, I’ll explain some of the practices I eliminated to avoid A04 (Insecure Design) issues in one of my projects, Alpha Connect Hub (now IoT Nerve).

Handling A04 across the entire project and all modules is my responsibility as a skilled full-stack developer to ensure that no cybersecurity issues are introduced due to weak design decisions.

To keep this article focused and practical, I will explain A04 using a specific module example.

Example Module: MQTT Broker Server Credentials

This module is responsible for setting up credentials (username and password) for the MQTT Authentication Service, which is required to connect to the MQTT Broker.

Insecure Practices Eliminated

One of the main vulnerabilities that must be rooted out in this module is:

Fetching the password on the frontend (even in hashed form)

The involvement of passwords or authentication keys on the frontend directly contributes to Insecure Design.

Another insecure practice that must not be allowed is:

Allowing the password-changing mechanism to proceed without verifying the original (old) password

Requiring the previous password ensures ownership verification and keeps access control intact.

Route Protection & OWASP Categorization

All routes used in this module are protected and require a server-issued token, enforced through middleware, before any real operation is performed.

Negligence in protecting such routes falls under A01 – Broken Access Control
The absence of proper route design, reasonable parameters, and a secure & safe output/result schema falls under A04 – Insecure Design

From Internship to Enterprise Development: My Journey into MDM, EMM & API Publishing

Hassam Fathe Muhammad — Sat, 01 Nov 2025 16:08:30 +0000

🔒 Disclaimer / Notice

This article is purely based on learning, exploration, and research into MDM, EMM, and API publishing technologies during my internship and personal projects.

No production-level deployments, enterprise bypassing, or unauthorized development for business gains were performed.

All experiments were done in local/demo environments and with educational intent.

The purpose of this write-up is to share knowledge and document my journey, not to promote or replicate enterprise deployments without proper authorization.

🏁 Starting Point: My Internship at Mercurial Minds

During my internship at Mercurial Minds (M.M), I was placed in the Enterprise Mobility Management (EMM) / Mobile Device Management (MDM) department.

At first, I wasn’t fully clear on what these systems were about — tools like Samsung Knox and other enterprise EMM platforms felt overwhelming.

But gradually, I discovered that EMM/MDM isn’t just about managing devices — it’s a core product area that many leading software companies invest in.

This was my first real exposure to enterprise-level technology, beyond the world of small-scale software projects.

🔍 Diving Deeper: From Confusion to Curiosity

As I got hands-on experience with an EMM/MDM portal on a demo server, my curiosity grew. With some research, I found that the portal was powered by the Entgra IoT Server.

Instead of stopping there, I pushed myself to self-learn:

Studied how the portal behaves behind the UI.
Explored the REST APIs that power MDM workflows.
Looked into open-source repositories on GitHub.
Broke down how Java, JDKs, and Maven tie together in Carbon Kernel–based projects.

At first, things like API gateways, publishing flows, and claim-based authentication seemed abstract. But slowly, the architecture started making sense — I realized these weren’t just “APIs,” they were enterprise connectors between identity, security, and data.

🧩 Connecting the Dots: From Internship to My Own Projects

While experimenting, I even evaluated Entgra UEM 6 (using my Alpha Tech business email). That opened doors to WSO2 API publishing features, which taught me that:

✅ APIs aren’t just direct DB calls — they’re published assets, controlled, secured, and monitored.

✅ A single published API serves all users/tenants, while tokens and claims decide whose data flows through.

✅ Enterprise systems solve the question:

“How do I ensure each user only sees their devices, even though everyone is calling the same endpoint?”

🧠 Applying It: Building My Own System

This was a big shift. I wasn’t just thinking like an intern anymore — I was thinking like:

A developer building scalable solutions.
A founder shaping my own product direction.

I applied these lessons in my own project — Alpha Connect Hub (under Alpha Tech):

Built a Node.js backend for device management.
Used WSO2 API publishing to expose those APIs securely.
Integrated OAuth2 / JWT-based access tokens to ensure each request is linked to a unique user identity.
Experimented with building a Java backend to simulate MDM/EMM workflows on a Carbon Kernel stack.

⚙️ Lessons From the Struggle

This journey wasn’t smooth:

Running large Carbon Kernel projects on macOS was painful.
Debugging JDK versions, Maven builds, and UEM server issues tested my patience.
Figuring out why GET /devices worked only via the API Gateway (and not as a direct DB call) forced me to learn about invoker endpoints, token claims, and mediation policies.

I learned that one API is published for everyone, but the token’s claims (like user_id) make it unique per user.

Every error — from a 401 auth failure to a class-not-found exception — taught me something new.

Through this struggle, I learned the real difference between project-level coding vs. enterprise-level development:

Projects require coding skill.

Enterprise systems require architecture, patience, and persistence.

🌐 What’s Next

I’m now preparing to set up a Linux server environment, since Carbon Kernel–based systems run more stably there compared to macOS.

My roadmap is clear:

Build enterprise-ready backend systems.
Combine MDM, EMM, and API publishing into scalable, secure products.
Use this foundation to grow Alpha Tech into a company that builds solutions, not just apps.

💡 Final Reflection

Looking back, this wasn’t just an internship. It was the spark that helped me:

Transition from learning projects → building products.
Move from coding → thinking enterprise.
See technology not just as tools, but as part of a bigger ecosystem of identity, security, and scale.

My journey into enterprise development has only just begun. 🚀