Render token names and logos as untrusted content

A token name is content supplied outside your application's trust boundary. It should never become executable HTML merely because a recognized aggregator returned it.

Use text rendering

Insert names and symbols through text-safe APIs or framework escaping. Avoid building HTML strings with raw metadata. OWASP's XSS prevention guidance distinguishes output contexts; HTML text, attributes, URLs and script data require different handling.

Bound displayed length and handle unusual Unicode visibly. A long symbol can break layout, while look-alike characters can make two assets appear identical. Keep the chain and contract address accessible so a visual label is never the sole identity check.

Remote assets need policy

Validate logo URLs, supported schemes and allowed content types. A remote image can reveal a visitor's request to its host and can change after it was first reviewed. If using an image proxy, constrain its destinations and response sizes rather than creating an unrestricted server-side fetch service.

Do not automatically turn arbitrary token metadata into a clickable wallet-connect URL. External links should clearly identify their destination and remain separate from the swap action.

Test the actual rendering path

Fixtures should contain angle brackets, quotes, line breaks, an extremely long name and a malformed logo URL. Inspect the final DOM or rendered component, not just a sanitizer helper. A second code path such as an error toast or token-search suggestion can reintroduce unsafe rendering.

The ERC-20 metadata methods are optional usability aids. Their presence does not certify a token, and their content should not receive privileges beyond ordinary untrusted display text.