Forem: Abdelghani El Mouak

A New Sharp but built with Rust x10 Faster.

Abdelghani El Mouak — Thu, 11 Dec 2025 09:52:46 +0000

Aissam Irhir

Dec 11 '25

Build a 10x Faster Image Upload API in 15 Minutes with Bun

#javascript #bunjs #webdev #api

Comments 3

6 min read

Hacking Mongoose: How I Built a Global Plugin to Stop Data Leaks 🛡️

Abdelghani El Mouak — Wed, 10 Dec 2025 22:47:47 +0000

Data leaks are the nightmare of every backend developer. You forget one .select('-password') in a new endpoint, and suddenly your user's sensitive data is exposed.

In this deep dive, I'm going to show you how FieldShield solves this problem by hacking into the Mongoose middleware chain to enforce security at the database abstraction level.

The Architecture Problem

In a typical Express/Mongoose app, security is often handled in the Controller layer:

// Controller
const user = await User.findById(req.params.id);
const safeUser = omit(user.toObject(), ['password', 'ssn']); // Manual filtering
res.json(safeUser);

This is prone to human error. If you access the database from a background job, a script, or a different controller, you have to remember to apply the same filter.

Security should be defined where the data is defined: in the Schema.

Enter FieldShield

FieldShield is a native Mongoose plugin that allows you to define per-field access roles directly in your schema definition.

const UserSchema = new Schema({
  username: { type: String, shield: { roles: ['public'] } },
  email:    { type: String, shield: { roles: ['owner', 'admin'] } },
  apiKey:   { type: String, shield: { roles: ['admin'] } },
  password: { type: String, shield: { roles: [] } } // Hidden from everyone
});

Under the Hood: The `pre('find')` Hook

The magic happens in how we intercept Mongoose queries. When you install FieldShield, we patch the Mongoose Query prototype to accept a context (roles).

Then, we register a global pre hook that inspects the query before it's sent to MongoDB.

// Simplified logic from src/query.ts
schema.pre('find', function() {
  const roles = this._shieldRoles; // Passed via .role('admin')
  const allowedFields = calculateAllowedFields(modelName, roles);

  // We force a projection on the query
  this.select(allowedFields);
});

This means the database only returns what you are allowed to see. The sensitive data never even enters your Node.js process memory.

The Challenge: Aggregation Pipelines

Simple queries are easy. But what about Model.aggregate()? Aggregations allow arbitrary stages that can reshape documents, making it hard to track fields.

FieldShield solves this by injecting a $project stage dynamically.

We analyze your pipeline and insert a protection stage right after the initial $match, ensuring that indexes are used efficiently but data is filtered before it flows through the rest of your pipeline (e.g., into $group or $lookup).

// Input
await User.aggregate([
  { $match: { status: 'active' } },
  // ... more stages
]).role('public');

// Actual Pipeline Executed
[
  { $match: { status: 'active' } },
  { $project: { username: 1, _id: 1 } }, // Injected by FieldShield
  // ... more stages
]

New in v2.2: Recursive Shield Inheritance 🔄

One of the tough technical challenges we just solved in v2.2 was Nested Object and Array Inheritance.

In MongoDB, preferences.theme is a distinct path from preferences. If you hide preferences.notifications, does the user still see the preferences object?

We implemented a recursive parser that synthesizes parent permissions based on their children.

If any child is visible, the parent field is visible.
If all children are hidden, the parent is hidden.
The parent inherits the union of all child roles.

This ensures you don't have to manually effectively duplicate shield configs on parent objects.

Performance Verification 🚀

Because FieldShield uses native MongoDB projections, it's actually faster than fetching the full document and filtering it in JavaScript.

Network I/O: Reduced (smaller payloads).
Memory: Reduced (fewer objects created).
CPU: Reduced (MongoDB handles the filtering in C++).

We Need You! 🫵

FieldShield is fully open source, and we have big plans for v3.0, including:

🛡️ Advanced wildcard policies
🔍 GraphQL integration
⚡ Caching for policy calculation

We are looking for contributors! Whether you're a TypeScript wizard, a Mongoose expert, or just want to write better docs, we'd love your help.

Good First Issues

Add more unit tests for edge cases
Improve documentation examples
Create a benchmark suite

Star the repo and check out the issues:
👉 github.com/kemora13conf/wecon-mongoose-field-shield

Let's build the standard for Mongoose security together.

Seeking Feedback: My React Project Structure for Scalability and Maintainability

Abdelghani El Mouak — Sun, 24 Nov 2024 19:00:51 +0000

Hey Devs! I'm working on a new React project and have put a lot of thought into structuring it for long-term scalability and maintainability. I'd love to get your feedback and hear any suggestions you might have.

I've opted for a primarily feature-based structure, centered around the concept of pages, to maximize component reuse and minimize code duplication. Here's a simplified overview:

src/ ├── App/ # Application entry and providers │ ├── Providers/ # Context providers (Theme, I18N) │ ├── Routes/ # Routing configuration │ └── Stores/ # Global state management (using Zustand/Redux/etc.) ├── Config/ # Application-wide configurations ├── Core/ # Core functionalities (Auth, Error handling) ├── Features/ # Page-based features │ ├── Home/ # Home page feature │ │ ├── Api/ # API calls related to Home │ │ ├── Components/ # Components specific to Home │ │ ├── I18N/ # Internationalization for Home │ │ ├── Pages/ # Page-level components │ │ │ └── index.tsx # Main Home page component. │ │ │ └── SuperAdminHome.tsx # Role Specific variant │ │ └── Stores/ # State management for Home (if needed) │ ├── Profile/ # Profile page feature (similar structure) │ └── Users/ # Users management feature │ ├── Api/ # API interactions │ ├── Components/ # Components (potentially subdivided) │ ├── Hooks/ # Custom Hooks │ ├── I18N/ # Internationalization │ ├── Pages/ # Page components │ │ ├── List/ # User list pages, Role based folder organization │ │ │ ├── index.tsx # Main users list component │ │ │ └── SuperAdminListActions.tsx # Variation if need be │ │ └── Create/ # Create user pages │ │ ├── index.tsx # Main user create component │ │ └── SuperAdminCreateUserForm.tsx # Variation if need be │ └── Stores/ # User-related state ├── Layout/ # Layout components (Header, Sidebar) ├── Shared/ # Shared components and utilities │ ├── Assets/ │ ├── Components/ │ └── Utils/ └── ...

Key Decisions and Considerations:

Page-centric Features: Organizing features around pages promotes component reuse and simplifies navigation.

Role-based Variations: Role-specific variations are handled within the page's folder (e.g., separate components or conditional rendering) to keep related logic together.

Clear Separation of Concerns: Dedicated folders for API calls, components, hooks, I18N, and stores enhance maintainability.

Shared for Reusability: Reusable components and utility functions live in the Shared directory.

Questions for the Community:

What are your thoughts on this structure? Do you see any potential drawbacks or areas for improvement?

How would you handle more complex role-based variations within this structure?

Any best practices or alternative approaches you would recommend?

Is there anything I've overlooked or could be done differently to further improve scalability and maintainability?

Thanks in advance for your insights! I'm eager to learn from your experiences and improve my project architecture.

reactjs #architecture #projectstructure #webdev #discuss