MB-R065 — No wildcard constraints

Why it Matters

Composer allows version constraints like * or x.* which match any version. Using wildcards is dangerous because it removes control over which package version gets installed. A new release (even with breaking changes or vulnerabilities) may be pulled in automatically without review, leading to unexpected regressions or exposure to untested code.

Requiring explicit, pinned, or semver-safe ranges (^, ~) ensures only intended versions are installed and security upgrades can be managed in a controlled way.

Verification Steps

# Search for wildcard constraints in composer.json
grep -E "\"[0-9]+\.\*\"" composer.json
grep -E "\"\*\"" composer.json

# Expected: no wildcards present

Remediation / Fix Guidance

1. Replace wildcard constraints with semver ranges or pinned versions:

   # Bad
   "vendor/extension": "*"
   "vendor/extension": "2.*"
   
   # Good
   "vendor/extension": "^2.4.5"
   "vendor/extension": "~2.4"

2. Use composer outdated to track available updates instead of relying on wildcards.
3. Review and test upgrades before applying them to production.
4. Automate dependency checks in CI/CD to block wildcard constraints from being committed.

Examples

# composer.json
"require": {
  "vendor/extension": "*"
}
# Any future version (including insecure) could be installed → FAIL

# composer.json
"require": {
  "vendor/extension": "^2.4.5"
}
# Safe range explicitly defined → PASS

References

• OWASP Top 10 — A06: Vulnerable and Outdated Components
• Composer Documentation — Versions and Constraints