Is Fake-Shop Detector safe?

Medium risk

Fake-Shop Detector is medium risk. Version 3.0.1 hardcodes an admin password in background.js and sends it as a Basic Auth header to api.infra.fakeshop.at on every page you open. We captured the request; the backend accepted it and returned data.

ÖIAT – Forschungsprojekt SINBADv3.0.1Chrome Web Store
45Risk
Who publishes it

ÖIAT – Forschungsprojekt SINBAD - no other listings under this identity, 3 shared hostnames

What this publisher told the store about itself, and the other listings that told it the same thing.

Publisher
ÖIAT – Forschungsprojekt SINBAD

Shared hosts - 3 hostnames

Hostnames hardcoded in this extension that few other listings call. That can mean one operator behind both, and it can equally mean a small shared vendor, so it is context rather than a conclusion. Hosts that many listings call are left out: they are services, not connections.

api.infra.fakeshop.at
Also called by 1 other listing: Fake-Shop Detector
fakeshop.at
Also called by 1 other listing: Fake-Shop Detector
text-api.malzwei.at
Also called by 1 other listing: Fake-Shop Detector

AI-generated. Findings may contain errors. Those marked Verified have been manually reviewed.

Publishers can request a review.

Findings

FakeShop Detector ships a hardcoded API password sent on every page

Version 3.0.1 hardcodes an admin password in background.js and sends it as a Basic Auth header to api.infra.fakeshop.at on every page you open.

We captured the request; the backend accepted it and returned data.

Severity
Medium unwanted
Type
Unexpected
CWE
CWE-522
Source
Dynamic sandbox
What actually happens
You did this

You open any web page in a browser tab.

The extension did this

The extension sends an analysis request to the vendor's site-risk-check API using a password that is hardcoded in the extension's own code.

The same fixed credential is reused for the daily cache refresh too.

The code that does this

The same hardcoded credential wired into both API calls

Readable version

renewCache()

background.js
async renewCache() {  const e = await f.A.get(`${this.apiUrl}/analyze/cache/`, {    headers: { "X-Referer": "FSD Plugin Cache" },    auth: { username: "admin", password: "qB4WtYRNq7Eao1" }  });  ...}

sendAnalyzeCallV3()

background.js
async sendAnalyzeCallV3(e, t) {  n = await f.A.post(`${this.apiUrl}/analyze/`, {    site_baseURL: e, clientID: m, requester: "Browser-Plugin"  }, {    headers: { "X-Referer": "FSD Plugin Analyze" },    auth: { username: "admin", password: "qB4WtYRNq7Eao1" }  });  ...}
Captured request
GEThttps://api.infra.fakeshop.at/analyze/cache/

200 OK. The site-risk list cache used to score every site you visit was returned using this credential.

Headers
X-Referer
FSD Plugin Cache
Authorization
Basic YWRtaW46cUI0V3RZUk5xN0VhbzE=
Why you can't catch this in DevTools

The Authorization header looks opaque, but it is only Base64, not encryption, of the credential hardcoded in the extension.

Decoded value
admin:qB4WtYRNq7Eao1
Third-party destinations
    • api.infra.fakeshop.at

    Vendor's own site-risk-detection backend; receives the hardcoded credential plus the URL of the site you're viewing on every request.

Reproduce it yourself

Rebuilds the Basic Auth header from the credential hardcoded in the extension and shows it matches what the extension actually sends.

Requires
  • Node.js 18+
decode-fsd-auth.js · js
const username = "admin";const password = "qB4WtYRNq7Eao1";const header = "Basic " + Buffer.from(`${username}:${password}`).toString("base64");console.log(header);// Expect: Basic YWRtaW46cUI0V3RZUk5xN0VhbzE=
How to run it
  1. 1Save as decode-fsd-auth.js.
  2. 2Run node decode-fsd-auth.js.
  3. 3Compare the printed header to one captured from the extension's own traffic.
Updated 30 September 2026fmnfaallpopfkmkcabhcbjapbeiefgon