Fix handling of Maps and other non plain object types

[timokoessler]

Summary by Aikido

Security Issues: 0	🔍 Quality Issues: 1	Resolved Issues: 0

⚡ Enhancements

• Detected and handled Map inputs by converting them to objects.
• Extracted strings from Map, Set, URLSearchParams, FormData, and Headers.
• Allowed MongoDB wrapper to inspect non-plain filters for injection detection.
• Expanded tests to exercise collection methods including insertMany scenarios.

🔧 Refactors

• Replaced plain-object checks with robust object-like detection and traversal.

^{More info}

[codecov]

Codecov Report

❌ Patch coverage is 92.81046% with 11 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...rabilities/nosql-injection/detectNoSQLInjection.ts	88.46%	9 Missing ⚠️
library/helpers/extractStringsFromUserInput.ts	97.26%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[aikido-pr-checks]

Silent catch in extractStringsFromUserInput swallows errors from the Reflect.ownKeys/Object.getOwnPropertyDescriptor loop; add logging or handle specific error cases instead of ignoring.

Show fix

Suggested change

	} catch {
	// Ignore errors
	} catch (error) {
	// Ignore errors from exotic objects/proxies that throw during reflection
	console.warn("Failed to extract strings from object via reflection:", error);

Details

✨ AI Reasoning
​A new try/catch was added around reflective property iteration in extractStringsFromUserInput. The catch clause is a bare, silent catch that only contains a comment saying errors are ignored. Silent catches can mask unexpected failures and make debugging harder. The try block uses Reflect.ownKeys/Object.getOwnPropertyDescriptor to inspect arbitrary objects, which can throw for some proxies or exotic objects; swallowing those silently hides the cause.

This finding points to the empty/silent catch introduced for the reflective iteration. Consider adding targeted error handling, logging, or restricting which objects are inspected to avoid silent failures.

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}

[aikido-pr-checks]

getOwnStringDataProperties performs Reflect.ownKeys + getOwnPropertyDescriptor per property and is used in recursive loops; cache or compute once per object to avoid repeated descriptor lookups.

Details

✨ AI Reasoning
​A helper was added that enumerates property keys using Reflect.ownKeys and calls Object.getOwnPropertyDescriptor for each key. That helper is then used in hot code paths (loops and reduce operations) where previously simple for-in iterations were used. The work per property (descriptor retrieval and filtering) is constant but is now performed repeatedly across recursive searches and array reductions, causing the total cost to scale worse with input size. Caching the list of string-valued own properties once per object or avoiding descriptor lookups when not necessary would avoid repeated work.

🔧 How do I fix it?
Move constant work outside loops. Use StringBuilder instead of string concatenation in loops. Cache compiled regex patterns. Use hash-based lookups instead of nested loops. Batch database operations instead of N+1 queries.

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}