# WEB-136 — No malware or insecure downloads served from the site

> The brand website must not host or promote malware, or application downloads served from non-secure locations.

- **Rule ID:** WEB-136
- **Layer:** Website (`WEBSITE`)
- **Checks:** `crawled website content`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the crawled website or policy page
- **Fix type:** Fix the website — no form edit clears it
- **Required by:** CTIA, AT&T
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/website/web-136/

## Why this rule exists

A link in a text message that ends in a drive-by download is the highest-severity outcome in the whole framework, so the destination is screened for it directly. The common cause is not malice: an unmaintained plugin on a small business site gets compromised, the owner never sees the injected script, and the first they hear of it is a registration refusal that says nothing about their site being hacked.

## How to fix it

Scan and clean the site, update the platform and plugins, and serve every download over https from your own domain. Done when a safe-browsing check on the domain comes back clear and no download link points at a plain-HTTP host.

## Example of a compliant value

```text
App links point at https://apps.apple.com/... and https://play.google.com/... rather than at a self-hosted APK.
```

## Common mistakes

- Cleaning the site does not clear the blocklist entry. Request a review with the safe-browsing service as well, or the domain reputation rules keep failing after the malware is gone.

## Notes

The landing-page malware screen is routed to WEBSITE by the catalog's layer-ownership rule, so it carries no MESSAGE_CONTENT alias: the message-side row was folded into this obligation rather than kept as a separate one.