ESLint InterlaceESLint Interlace
Plugin: operabilityRules

require-data-minimization

ESLint rule documentation for require-data-minimization

📡 Live from GitHub — This documentation is fetched directly from require-data-minimization.md and cached for 6 hours.

Identifies excessive data collection patterns that violate privacy principles

Identifies excessive data collection patterns that violate privacy principles

Severity: 🟡 MEDIUM
CWE: CWE-213: Exposure of Sensitive Information Due to Incompatible Policies
OWASP Mobile: M6: Inadequate Privacy Controls

Rule Details

This rule detects when applications collect excessive user data by flagging objects with more than 10 properties that include common PII fields (email, name, phone, address).

Why This Matters

Collecting excessive user data increases privacy risks and regulatory compliance burden. GDPR Article 5(1)(c) and CCPA Section 1798.100(c) require organizations to minimize data collection to only what is necessary for the stated purpose. Excessive data collection:

  • Increases attack surface for data breaches
  • Creates regulatory compliance risks (GDPR fines up to €20M or 4% of revenue)
  • Violates user privacy expectations
  • Requires additional security controls and retention policies

❌ Incorrect

// Collecting excessive user data (15 properties)
const userData = {
  email: req.body.email,
  name: req.body.name,
  phone: req.body.phone,
  address: req.body.address,
  age: req.body.age,
  gender: req.body.gender,
  occupation: req.body.occupation,
  income: req.body.income,
  education: req.body.education,
  maritalStatus: req.body.maritalStatus,
  hobbies: req.body.hobbies,
  favoriteColor: req.body.favoriteColor,
  shoeSize: req.body.shoeSize,
  bloodType: req.body.bloodType,
  mothersMaidenName: req.body.mothersMaidenName,
};

// Collecting data not needed for the feature
async function createNewsletter Subscription(user: any) {
  return db.subscribers.create({
    email: user.email,
    name: user.name,
    phone: user.phone, // ❌ Not needed for newsletter
    address: user.address, // ❌ Not needed
    ssn: user.ssn, // ❌ Definitely not needed!
    creditCard: user.creditCard, // ❌ Not needed
  });
}

✅ Correct

// Collect only necessary data for newsletter subscription
const newsletterData = {
  email: req.body.email,
  preferredName: req.body.name, // Optional, for personalization
};

// Separate data collection for different purposes
async function createNewsletterSubscription(email: string, name?: string) {
  return db.subscribers.create({
    email, // Required for sending newsletter
    name, // Optional, for "Hi {name}" personalization
    subscribedAt: new Date(),
  });
}

// Collect data progressively based on actual need
async function updateUserProfile(
  userId: string,
  updates: Partial<UserProfile>,
) {
  // Only collect additional data when user explicitly provides it
  return db.users.update(userId, updates);
}

Known False Negatives

The following patterns are not detected due to static analysis limitations:

Data Collection via Spread Operators

Why: Spread operators copy all properties, but we can't analyze the source object statically.

// ❌ NOT DETECTED - Spread may copy excessive fields
const userData = {
  email: req.body.email,
  ...req.body, // Copies all fields from request
};

Mitigation: Explicitly list required fields instead of using spread operators for user data.

Data Collection in Class Constructors

Why: We only analyze object literals, not class instantiation patterns.

// ❌ NOT DETECTED - Constructor parameters
class User {
  constructor(
    public email: string,
    public name: string,
    public phone: string,
    public address: string,
    // ... 10 more properties
  ) {}
}

Mitigation: Review class constructors manually for data minimization compliance.

Dynamic Property Assignment

Why: Properties added via bracket notation or Object.assign are not statically analyzable.

// ❌ NOT DETECTED - Dynamic assignment
const userData = {};
Object.assign(userData, req.body); // Copies all fields

Mitigation: Use explicit property access and validation schemas (e.g., Zod, Joi).

⚙️ Configuration

This rule has no configuration options. It flags any object literal with >10 properties that contains common PII fields.

📚 References

On this page

No Headings