087 Should You Copy and Paste That Award Badge

Website Security & Best Practices

Every piece of third-party code adds another dependency. Sometimes the safest—and simplest—solution is to keep the badge local.

From time to time, a business receives an exciting message: it has won an award, earned a recommendation, or been selected as one of the best businesses in its area.

There is only one small catch:

The business never applied for the award.

The message often includes a badge and a block of code to paste into the company’s website. The badge may look professional, and the recognition may be legitimate, but should the supplied code automatically be added to the site?

Not necessarily.

At Zehr.net, we take a cautious approach to third-party website code. Even when the badge itself appears harmless, we first ask a more important question:

Does this outside code provide enough value to justify the added dependency, complexity, and trust?

In many cases, the answer is no.

What Is an Award Badge Really Doing?

An award badge usually serves more than one purpose.

For the business receiving it, the badge may provide:

• Recognition
• Social proof
• A sense of credibility
• A link to a page describing the award

For the company supplying it, the badge may provide:

• A backlink from the business’s website
• Brand exposure
• Referral traffic
• Information about visits to pages displaying the badge
• A growing network of websites that depend on its files

That does not automatically make the badge dishonest or harmful. However, it does mean the arrangement may benefit the award provider as much as—or more than—the business receiving the award.

The Difference Between a Badge and Badge Code

There is an important distinction between displaying an award and installing the code supplied by the award company.

A badge can be nothing more than an image with a link.

This version is simple. The image is stored on the business’s own website, while the link can still direct visitors to the original award page.

By comparison, supplied badge code may depend on external stylesheets, images, fonts, scripts, or other resources controlled by the award provider.

That creates a very different relationship.

External Stylesheets Create an Ongoing Dependency

A badge provider may ask the website to load a css stylesheet from its server:

Each time someone visits the page, the visitor’s browser contacts the outside server to request that file.

This can introduce:

• Another DNS lookup
• Another secure connection
• Another external request
• Another possible point of failure
• Another organization receiving information associated with the page request

The outside company also retains control of the stylesheet. It can update, replace, move, or remove the file without making any changes to the business’s website.

Today, the stylesheet may simply position a badge. In the future, it could be changed in ways the website owner did not anticipate.

External Images Also Contact Another Server

Even when no JavaScript is present, a badge may load an image or background graphic from the provider’s server. When that image loads, the browser makes another outside request.

The request may reveal ordinary technical information such as:

• The visitor’s IP address
• The browser and device being used
• The time of the request
• The page referring the request
• An approximate geographic location based on the IP address

The award provider may use this information only for routine server logs or analytics. The concern is not that every outside resource is malicious. The concern is that the business does not need to create this connection merely to display a small image.

The Code Can Be More Complicated Than the Badge Requires

Some badge code includes deeply nested HTML, inline styles, embedded SVG graphics, click-handling instructions, externally hosted backgrounds, and multiple links.

That is a surprising amount of code to display what is essentially a small award image.

Unnecessary complexity can make a website:

• Harder to maintain
• Harder to troubleshoot
• More difficult to keep accessible
• More dependent on another company
• More vulnerable to future compatibility problems

A useful web-development principle is:

Do not add five moving parts when one simple part will do the job.

Third-Party Resources Increase the Trust Boundary

Security is not only about identifying code that is obviously dangerous. It is also about limiting how many outside systems a website must trust.

Whenever a website loads a file from another domain, it depends on:

• The provider’s server security
• The provider’s account security
• The provider’s domain and DNS security
• The availability of the provider’s network
• The provider continuing to maintain the same file
• The provider not changing the file in an undesirable way

The badge provider may have excellent security. However, if the badge can be displayed without creating that dependency, there may be no reason to accept the extra risk.

Good security often comes from removing things that are unnecessary.

What Happens If the Badge Company Changes Something?

Externally hosted badge code may work perfectly when it is first installed. But what happens several years later?

The provider might:

• Rename the stylesheet
• Move the image files
• Change the badge design
• Modify its domain structure
• Close the award program
• Stop maintaining older badges
• Allow its domain to expire

The result could be a missing image, broken layout, strange formatting, or a dead link on the client’s website.

A locally stored badge remains under the website owner’s control.

Is the Award Promoting the Client—or the Award Company?

An award badge should highlight the business that received the recognition.

However, some badges prominently display the award provider’s name and link to its main website. In effect, the client’s website becomes an advertisement for the company issuing the badge.

That may be acceptable when the award is respected and meaningful. It is still worth examining whether the recognition provides real value.

Before displaying an award, consider:

• Is the award provider reputable?
• Is there a real page about the client?
• Does the page contain accurate information?
• Does the award appear to be selective?
• Is the recognition meaningful to potential customers?
• Does the destination page contain excessive advertising?
• Does the badge strengthen the client’s reputation?

Not every badge deserves a place on the website simply because it arrived in an email.

Our Preferred Approach

When an award appears legitimate and useful, we can usually display it without installing the supplied third-party code.

Our preferred process is:

1. Review the organization offering the award.
2. Verify that a real page exists for the client.
3. Check that the information on that page is accurate.
4. Save an approved copy of the badge image.
5. Resize and optimize the image for the website.
6. Store the image locally on the client’s server.
7. Add appropriate alternative text.
8. Link the image to the legitimate award page when beneficial.

This allows the client to display the recognition while keeping the website cleaner and more independent.

A Simple, Safer Badge:

link code with
   href=""
   target="_blank"
   rel="noopener noreferrer"
image code with
    src=""
    alt=""
    width="174"
    height="135"
    loading="lazy"

A small block of HTML provides everything most award badges need:

• A locally hosted image
• Descriptive alternative text
• Defined image dimensions
• Optional lazy loading
• A link to the award page
• Additional protection when opening a new tab

What Does rel="noopener noreferrer" Do?

When a link uses target="_blank", it opens the destination in a new browser tab or window.

Adding:

rel="noopener noreferrer"

provides two useful instructions.

noopener

noopener prevents the newly opened page from receiving access to the original page through the browser’s window.opener connection.

This helps prevent the destination page from attempting to control or redirect the original tab.

noreferrer

noreferrer tells the browser not to send the address of the referring page to the destination as referral information.

It also provides behavior similar to noopener in modern browsers.

These attributes are useful when opening an outside website in a new tab, especially when the destination is not under the same ownership as the original site.

What Does loading="lazy" Do?

The attribute:

loading="lazy"

tells the browser that it may delay loading the image until the image is near the visible portion of the page.

This can improve initial page performance when an image appears farther down the page.

Lazy loading is especially helpful for:

• Photo galleries
• Long articles
• Pages with many images
• Badges placed in the footer or lower sections

Images that appear immediately at the top of the page may not benefit from lazy loading because they need to be visible as soon as the page loads.

Why Include Image Width and Height?

Defining the image dimensions helps the browser reserve the correct amount of space before the image finishes loading.

Should Every Third-Party Tool Be Avoided?

No.

Some outside services provide enough value to justify their addition. Examples might include secure payment systems, carefully selected analytics, mapping services, appointment scheduling, or accessibility-tested video platforms.

The key is to make the decision intentionally.

Before adding any third-party feature, ask:

• What useful function does it provide?
• Can the same result be achieved locally?
• What information is shared with the provider?
• What happens if the service stops working?
• Can the provider change the code after it is installed?
• Will it affect performance or accessibility?
• Is the added complexity justified?

A payment processor may be worth the dependency because it provides a specialized and necessary service.

A remotely hosted image badge usually does not require the same level of trust.

Simple Websites Are Often Stronger Websites

Modern websites can quickly accumulate outside code:

• Analytics scripts
• Social media feeds
• Chat widgets
• Review widgets
• Remote fonts
• Advertising networks
• Tracking pixels
• Award badges
• Embedded videos
• Third-party design libraries

Each addition may seem small. Together, they can make a website slower, more fragile, more difficult to maintain, and more dependent on companies outside the website owner’s control.

There is real value in keeping a website simple.

Every external dependency should earn its place on the page.

The Zehr.net Approach

At Zehr.net, we do not automatically paste third-party code into a client’s website simply because another company supplied it.

We review what the code does, what outside resources it loads, what information may be shared, and whether there is a simpler way to accomplish the same goal.

When an award is legitimate and worth displaying, a locally hosted image with a carefully reviewed link is often the better solution.

The client still receives the benefit of the recognition.

The award page can still receive a link.

Visitors can still learn more.

But the client’s website remains cleaner, faster, easier to maintain, and more firmly under the client’s control.

Final Thought

The question is not always:

“Is this code dangerous?”

A better question may be:

“Is there a good reason to add this code at all?”

If a simple local image can do the same job, adding a collection of externally controlled files may provide little benefit.

Sometimes the best website improvement is not another feature, another widget, or another block of code.

Sometimes the best decision is to keep the website simple.