Skip to content

fix(server): guard collection lookup against prototype keys#488

Open
itsmelouis wants to merge 1 commit into
nuxt:mainfrom
itsmelouis:fix/server-prototype-keys
Open

fix(server): guard collection lookup against prototype keys#488
itsmelouis wants to merge 1 commit into
nuxt:mainfrom
itsmelouis:fix/server-prototype-keys

Conversation

@itsmelouis
Copy link
Copy Markdown

🔗 Linked issue

No related issue.

📚 Description

src/runtime/server/api.ts looks the collection up via collections[collectionName], which also resolves inherited keys from Object.prototype (__proto__, toString, constructor, ...). The resolved value gets passed down to getIcons(),
which is not designed to handle it and crashes --> 500.

The fix is one line: gate the lookup with Object.hasOwn(collections, collectionName) so only own keys are considered. Unknown / prototype keys now fall through to the API fallback (or 404 if fallbackToApi is disabled), same as any other unknown collection.

Repro in the playground:

pnpm dev
curl -i 'http://localhost:3000/api/_nuxt_icon/toString.json?icons=bad'

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 17, 2026

Review Change Stack

📝 Walkthrough

Walkthrough

The server icon API adds an explicit existence check before accessing the bundled collections map. Instead of relying solely on optional chaining to handle potentially missing collections, the code now verifies the collection exists using Object.hasOwn(collections, collectionName) before attempting to load it. This ensures non-existent collections consistently resolve to null rather than undefined.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: guarding collection lookup against prototype keys, which is the core fix in this one-line change.
Description check ✅ Passed The description is directly related to the changeset, explaining the problem (prototype key resolution), the solution (Object.hasOwn guard), and providing a reproduction case.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
src/runtime/server/api.ts (1)

31-31: 💤 Low value

Optional: Remove redundant optional chaining.

Since Object.hasOwn(collections, collectionName) guarantees the property exists, the optional chaining ?.() on line 31 is technically redundant. You could simplify to collections[collectionName]() for clarity. However, keeping the defensive optional chaining is perfectly acceptable.

♻️ Optional simplification
 const collection = collectionName && Object.hasOwn(collections, collectionName)
-  ? await collections[collectionName]?.()
+  ? await collections[collectionName]()
   : null
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/runtime/server/api.ts` at line 31, The call uses redundant optional
chaining: after confirming Object.hasOwn(collections, collectionName), replace
the defensive call expression collections[collectionName]?.() with a direct call
collections[collectionName]() to simplify the code; locate the expression using
the symbols collections and collectionName and update that invocation
accordingly (you may keep the optional chaining only if you prefer the extra
defensive style).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/runtime/server/api.ts`:
- Line 31: The call uses redundant optional chaining: after confirming
Object.hasOwn(collections, collectionName), replace the defensive call
expression collections[collectionName]?.() with a direct call
collections[collectionName]() to simplify the code; locate the expression using
the symbols collections and collectionName and update that invocation
accordingly (you may keep the optional chaining only if you prefer the extra
defensive style).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 17722e55-2ecb-488e-9131-4def31b92bc6

📥 Commits

Reviewing files that changed from the base of the PR and between 7cafddc and 3b25a8d.

📒 Files selected for processing (1)
  • src/runtime/server/api.ts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant