Every Chrome Web Store Readiness Audit check

A missing or generic name like "Extension" or "App" fails Chrome Web Store review outright — the store rejects submissions where the name field is absent or indistinguishable from the category. Beyond rejection, a non-descriptive name tanks organic discoverability; Chrome Web Store search indexes the `name` field directly, so a vague name means users searching for your specific functionality simply won't find you. The chrome-cws-naming policy enforces this at submission time, making a bad name a hard gate, not a soft warning.

Why this severity: Critical because a missing or generic name causes Chrome Web Store rejection, blocking distribution entirely.

The manifest `description` is the first copy Chrome Web Store renders below the extension name in search results. A vague or absent description like "A useful extension" gives reviewers and users no signal about what the extension actually does, depressing install rates and creating friction in review. Chrome Web Store uses this field in its keyword index, so a weak description directly limits organic discoverability. Descriptions under 10 words fail the chrome-cws-listing-requirements threshold and are flagged during review.

Why this severity: Medium because a vague description harms discoverability and slows review approval but does not block submission outright.

Chrome Web Store requires PNG icons at 16px, 48px, and 128px before an extension can be submitted. Missing any size causes an upload error; the store does not auto-resize. Inconsistent icons — different colors or designs across sizes — signal low production quality and erode user trust at the moment of install decision. The 128px icon is the primary visual in the store listing grid; a missing or mismatched icon directly suppresses conversion from store impression to install.

Why this severity: High because missing required icon sizes causes a hard upload rejection from the Chrome Web Store submission form.

Chrome Web Store requires the `version` field to use a dot-separated numeric format (e.g., `1.0.0`). A version string prefixed with `v` or using fewer than three segments is rejected by the store validator. Beyond compliance, a version at `0.0.1` signals an untested pre-release to both reviewers and users, reducing install confidence even after approval. Proper semver also enables the store's update delivery mechanism — malformed versions cause update notifications to fail, leaving installed users on stale builds.

Why this severity: High because a malformed version string triggers store validator rejection and breaks the auto-update delivery mechanism for installed users.

Chrome Web Store enforces a single-purpose policy (chrome-cws-single-purpose): extensions that claim to do three or more unrelated things — tab management AND ad blocking AND password management — are rejected or removed from the store. Even if the extension passes initial review, Google's automated systems flag multi-purpose behavior post-publication, which can result in suspension. A clearly stated singular purpose also reduces user confusion about what permissions the extension actually needs, decreasing install abandonment.

Why this severity: Medium because multi-purpose descriptions risk post-publication removal under the chrome-cws-single-purpose policy, not just initial rejection.

Overly broad permissions like `<all_urls>` give an extension read and write access to every website a user visits — every bank page, every login form, every private document. Chrome Web Store policy (chrome-cws-permissions-policy) enforces least-privilege; extensions with unjustified broad permissions fail review. Beyond review, broad permissions are the primary attack surface for supply-chain compromise: if your extension is hijacked, `<all_urls>` turns it into a credential harvester. OWASP A01 (Broken Access Control) and CWE-272 (Least Privilege Violation) both apply.

Why this severity: Critical because unjustified `<all_urls>` grants full read/write access to all sites the user visits, enabling credential theft on account takeover if the extension is compromised.

Chrome Web Store requires a privacy policy for any extension that handles user data, and GDPR Article 13 mandates disclosure of data collection at the point of data gathering. A broken or missing privacy policy URL causes store rejection. Beyond compliance, a placeholder policy ("To be determined") exposes you to regulatory action in the EU and UK — regulators treat a published placeholder as a misrepresentation, not an absence. Users who can't find your privacy policy are far more likely to uninstall or leave negative reviews flagging trust concerns.

Why this severity: Critical because a missing or broken privacy policy causes Chrome Web Store rejection and creates GDPR Article 13 compliance exposure for EU users.

`unsafe-eval` in a Chrome extension's Content Security Policy permits dynamic code execution via `eval()`, `new Function()`, and related patterns — exactly the primitives an attacker uses in an XSS payload. Chrome Web Store (chrome-cws-csp-policy) blocks extensions with `unsafe-eval` in their CSP outright; there is no exception process. Beyond store rejection, allowing `eval()` in an extension context means any cross-site scripting vulnerability in the extension's pages can escalate to full browser API access, violating OWASP A03 (Injection) and CWE-95 (Improper Neutralization of Directives in Eval).

Why this severity: High because `unsafe-eval` causes Chrome Web Store rejection and enables XSS-to-extension-API escalation if any content is rendered dynamically.

Chrome Web Store (chrome-cws-code-readability) prohibits obfuscated code — not minification for size, but intentional renaming and encoding that hides what the extension actually does. Extensions caught with obfuscated logic are removed from the store and may be permanently banned. From a user-trust perspective, an extension that hides its logic cannot be independently audited, which is a red flag for the millions of users who rely on community security reviews. ISO 25010 maintainability standards treat intentional obfuscation as a defect, not a feature.

Why this severity: High because obfuscated code triggers store removal and prevents independent security auditing, hiding potentially malicious behavior from users.

Chrome Web Store's user data policy (chrome-cws-user-data-policy) requires that any extension collecting data disclose what is collected and why. GDPR Article 5 adds a lawfulness requirement: processing personal data without transparent disclosure is a violation, not just a policy gap. An extension with `tabs`, `cookies`, or `webRequest` permissions can access sensitive browsing behavior; users have no visibility into whether that data leaves their device unless you explicitly document it. Undisclosed data collection is also a top source of negative store reviews and user complaints that trigger review team investigations.

Why this severity: Medium because undisclosed data collection violates chrome-cws-user-data-policy and GDPR Art. 5, but the impact depends on whether sensitive data is actually transmitted.

Chrome Web Store requires at least one screenshot before an extension can go live; the store upload form blocks submission without one. Screenshots at the specified 1280x800 or 640x400 dimensions are how the majority of users decide whether to install — a missing screenshot means a blank listing that converts at near-zero. Store search results show the primary screenshot thumbnail as the visual hook; without it, your listing is invisible compared to competitors. The chrome-cws-screenshots policy treats this as a hard submission requirement.

Why this severity: High because zero screenshots block Chrome Web Store submission entirely and eliminate the primary visual conversion surface for potential installs.

The 1400x560 marquee tile is the banner Chrome Web Store uses when featuring an extension in editorial collections or category spotlights. Without it, your extension is ineligible for featured placement — one of the highest-traffic discoverability surfaces in the store. Extensions in featured sections see significantly higher install rates than those found only through search. While not a hard submission blocker, the chrome-cws-marquee-tile recommendation is followed by every extension that achieves meaningful organic growth through store discovery.

Why this severity: Low because a missing marquee tile forfeits editorial featuring opportunities but does not block submission or break functionality.

The 440x280 small promotional tile appears in the extension recommendation rows that Chrome shows users on the new-tab page and in related-extension suggestions. These placements are algorithm-driven and trigger when a user has related extensions installed — a high-intent audience. Without the small tile, your extension is excluded from these recommendation surfaces. For extensions in competitive categories like productivity or developer tools, recommendation placements often drive more installs than store search.

Why this severity: Low because a missing small tile forfeits algorithmically-driven recommendation placements but does not block submission or affect existing users.

Chrome Web Store screenshots with excessive padding, blurry text, or low resolution signal an unpolished extension to potential users at the exact moment of install decision. Users comparing several extensions in a category will default to the one whose screenshots look professional. Beyond conversion, the store's quality guidelines (chrome-cws-screenshot-quality) note that screenshots must accurately represent the extension — padding-heavy images that obscure actual UI can trigger reviewer requests for replacement assets, delaying publication.

Why this severity: Low because poor screenshot quality reduces install conversion and can delay review, but does not block submission or affect security.

Chrome Web Store reviewers test extension functionality manually. If your extension requires authentication to demonstrate its core features, reviewers without working test credentials will mark the submission as "Unable to review" and reject it. This is one of the most common avoidable rejection causes for extensions that connect to external services. The chrome-cws-test-account policy is explicit: extensions requiring login must provide valid test credentials in the submission notes, not the public README where they could be abused.

Why this severity: High because missing test credentials for authenticated extensions causes reviewer rejection as "Unable to review," requiring resubmission and adding weeks to launch timeline.

Chrome Web Store reviewers scrutinize permissions that appear broader than the extension's stated purpose. Without documented justification for each permission, reviewers must guess whether a permission is necessary — and they default to rejection when they can't. The chrome-cws-permission-justification best practice exists precisely because extensions are regularly removed for having permissions that look suspicious but are actually legitimate. Documenting every permission also surfaces over-permissioning during development, before it becomes a rejection.

Why this severity: Medium because undocumented permissions slow review and increase rejection risk when reviewers cannot verify each permission is necessary.

Chrome Web Store requires a monitored developer contact so users and the review team can report issues, abuse, and policy violations. An invalid or placeholder email (like `dev@example.com`) means user complaints go nowhere — the store's dispute escalation process routes through developer contact, and unresponsive developers are flagged for suspension. A real contact email is also how Chrome notifies you of impending policy violations before they become removals, making it a practical early-warning mechanism.

Why this severity: Info because a missing or placeholder contact email blocks user feedback and policy violation notifications but does not directly affect extension functionality or immediate submission.

Miscategorized extensions are harder for users to find through browse and recommendation surfaces, because Chrome Web Store's category filters and featured placements are category-specific. An extension placed in Developer Tools when it belongs in Productivity won't appear in Productivity recommendations, missing the audience most likely to install it. Language mismatches — a Chinese-language extension claiming English-only — generate user complaints and one-star reviews from users who installed expecting English UI and got something unreadable.

Why this severity: Low because category and language mismatches reduce discoverability and cause user complaints but do not block submission or affect extension security.