T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/influencer_report.py:328
- Finding
- Unscoped Video Library Queries Can Analyze Unrelated Creator Content<![CDATA[ ## Vulnerability Details **File Location**: `scripts/influencer_report.py`, lines 328-346 **Vulnerability Type**: Improper data scoping and insufficient creator-identity validation **Risk Level**: Medium ### Vulnerable Code ```python # Step 2: List videos all_videos = v1_list_videos(v1_key) # Step 3: Search for relevant content search_results = v1_search("creator talking to camera", v1_key, top_k=args.scrape_count) # Extract video URLs from library for v in all_videos[:args.scrape_count]: url = v.get("video_url") or v.get("url") or v.get("videoUrl", "") if url: video_urls.append(url) # Also check search results for r in search_results: url = r.get("video_url") or r.get("url") or r.get("videoUrl", "") if url and url not in video_urls: video_urls.append(url) ``` ### Technical Analysis When profile mode is used, the script first initiates scraping for the requested profile. It then calls `v1_list_videos`, which lists all videos available in the API account's V1 library, and performs a generic search for `"creator talking to camera"`. The returned records are selected solely by position and URL presence. The script does not verify that any selected video belongs to the requested profile, matches `args.handle`, originated from the current scraper task, or has the expected canonical creator identifier. Consequently, the operation exceeds the minimum creator-specific data scope required by the declared functionality. In an account containing content for multiple creators, videos unrelated to the requested influencer can be sent to the V2 transcript and metadata services and incorporated into the resulting report. The external API calls themselves are consistent with the declared Memories.ai-based analysis workflow. API credentials are sent only in authorization headers to hardcoded Memories.ai endpoints, an ...[truncated 2118 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Bind results to the current scraper task** - Preserve the task ID returned by `v1_scrape`. - Poll a documented task-status endpoint and consume only records explicitly associated with that task. - Do not use an account-wide library listing as a substitute for task-specific results. 2. **Apply creator-specific server-side filters** - If the API supports filters, query by canonical profile URL, platform creator ID, username, ingestion batch, or task ID. - Replace the generic `"creator talking to camera"` search with a query constrained to the requested creator. 3. **Validate every result locally** - Normalize the requested profile URL and returned video URLs. - Confirm platform, creator handle, and canonical creator identifier before adding a video to `video_urls`. - Reject records with missing or ambiguous ownership metadata rather than assuming they belong to the requested creator. 4. **Avoid silent fallback to unrelated data** - If the current scrape does not return enough validated videos, report insufficient data. - Never fill the requested count using unrelated global library entries. 5. **Separate tenants and ingestion batches** - Use isolated libraries or namespaces where supported. - Ensure users cannot retrieve records belonging to unrelated customers or creator-analysis jobs. 6. **Add regression tests** - Populate a test library with videos from several creators. - Verify that a report request includes only URLs belonging to the requested creator. - Test malformed URLs, look-alike handles, mixed platforms, duplicate results, and records without creator metadata. A safe implementation should use a task-scoped API response and perform an explicit ownership check before each URL is submitted for V2 analysis. ]]>
