Malvertising is on the rise and every publisher understands that clicking on a redirect is digital quicksand. That’s why for more than half a decade, SafeFrame containers have been an ad security staple of the digital media industry. Developed by the IAB with industry-wide input and designed for scalability and efficiency, SafeFrame technology tightened up vulnerabilities in ad slots that malvertisers and scammers had long used to launch attacks.
SafeFrames protect websites by creating a container around advertising content. That way, even if an ad contains malware or any other potentially unwanted program, it won’t impact the rest of the website. SafeFrames do this while still enabling communication between the webpage and the served content through an API. SafeFrames even allow a publisher to decide what page data can be seen by which advertisers or vendor partners.
This guide will dig into the SafeFrame container and explore the pros and cons of implementing SafeFrame to control ad behavior and fight forced redirects and malvertising.
SafeFrame vs. iFrame
SafeFrames and iFrames both protect websites from external content, but SafeFrames offer more options for interaction between the ad and the website content, and more data about ad performance.
SafeFrames and iFrames are similar, but they are not exactly the same. An iFrame is like a window that can be placed on web pages with a clear view of the content produced by an advertiser or network. However, when an ad is placed inside an iFrame, the ad stays inside the boundaries and doesn’t interact with the other elements of the particular website page, leading to inflexible advertising.
A SafeFrame, on the other hand, is an API-capable iFrame that opens a unified communication path between advertising content and page content. The API enables transparent and rich interactions between the ad and the content served on the websites and allows both the publisher and the advertiser to receive data about the performance of the ads on a given domain.
iFrame pros and cons
Although iFrames are effective in preventing external access to publisher content, they introduce their own security risks and limit ad capabilities.
For example, the advertiser cannot make changes to the shape and size of the iFrame to accommodate various creatives. iFrames also prevent the ad from collecting data for performance and viewability metrics, meaning advertisers and publishers can’t use the data to determine the value of the inventory in a given domain. Stakeholders can’t use tracking cookies to keep track of a target’s browsing history, request information, or utilize other add-ons or other resources to leverage the full value of their campaigns and ads. Therefore, they are not an ideal solution for advertising.
What is SafeFrame googlesyndication?
Google Adsense loads creative files into the SafeFrame from the URL googlesyndication.com.
Therefore, if you remove Googlesyndication, you can’t serve ads from Google Adsense in your SafeFrame. It isn’t limited to the Google Chrome browser, but also loads creatives like banner ads, when visitors are using Mozilla Firefox or Safari. However, if you are experiencing problems with ads on your site, it is likely that SafeFrame Googlesyndication is not to blame, but rather the result of a bad ad being served through the Google Adsense network. Therefore, there is no need to delete or block Google syndication on a post, website, or app.
What is SafeFrame used for?
SafeFrames are used to keep websites and apps safe and protect sensitive data from malware, while still giving the publisher and advertiser more granular control over ad content.
Today, SafeFrames are not only advisable — they should be considered essential for ad security. In most interactive advertising models, the publisher implements the SafeFrame container but a third party such as an ad server or ad verification vendor may also host the SafeFrame upon agreement from the publisher.
DSPs often require data from publishers that they can’t access through SafeFramed ads. The creative code files might need to be modified by the advertiser or their partners in order to load or render properly in SafeFrames.
What is SafeFrame 2.0?
SafeFrame 2.0 was created to better support header bidding tech and provide app protection in addition to websites.
SafeFrame 1.0 was the initial iteration that enabled ad content interaction and gave publishers more control. With SafeFrame 1.0, the publisher can make decisions about acceptable ad expansions and what data the creative code can access. The publisher can also prevent third parties from accessing users’ personal information — things like form data, passwords, banking data, credit card information, and other sensitive information.
However, SafeFrame 1.0 has limitations. It doesn’t report viewability measurements, the publisher still has to modify their GPT (Google Publisher Tags) to enable ad expansions, and SafeFrame is not supported in any mobile app (only on the mobile web).
SafeFrame 2.0 aims to address those issues and better support header bidding tech. It’s designed to align with MRAID and to support all HTML ads including those on a mobile app. It supports ad expansions across all current formats, without prior “knowledge” of the ad’s final dimensions, which vary by browser and device (for example, Apple products and platforms like Safari and Mac may be different than a standard personal computer).
The new version of SafeFrame is also meant to better align with browser features like sandboxing, the intersection observer, and feature policy — features that remove functionalities from SafeFrame that already exist in popular browsers like Google Chrome and Safari. In fact, with version 2.0, the IAB recommends additional features to build on SafeFrame capabilities without additionally straining its API.
Are SafeFrame containers a substitute for ad security and verification solutions?
SafeFrames are a great, base-level security tool, but shouldn’t be used in place of an ad security group vendor.
Addressing the breadth and complexity of malvertising threats in the programmatic ecosystem is not part of SafeFrame tech’s core capability, and SafeFrames are not a substitute for verification or security tools. Better ad security tools should be implemented to ensure malicious (ads that contain a virus, or promote extensions with a virus), non-compliant, or spammy ads are never served on your site.
In other words, although SafeFrames are reasonably effective against a virus and most malicious advertisers, they are not exactly a powerful anti-malware tool or a cleanad product. That’s because with a SafeFrame, you are still creating a line of communication that sophisticated bad actors can abuse through cross-site scripting, extensions, and other vulnerabilities found within your browser.
Publishers have tried to block forced redirects, various types of virus, and malvertising by implementing DIY solutions. They have tried to write code, adjust price floors and ask their ad-ops ops teams to manually track down malicious sources and delete them before they download onto a computer. These solutions are often slow, resource-heavy, or ultimately ineffective.
Ad security and quality solutions are far better suited to prevent not only malicious ads but also non-compliant and otherwise low-quality ads.
Gauging the effectiveness of current tools
As sophisticated as malvertisers and scammers have become, it’s often extremely difficult for a publisher to realize their SafeFrames are no longer cutting it until it’s too late.
Here are some signs publishers can watch for to recognize it’s time to move beyond DIY solutions:
1. User complaints
People are often quick to speak up when they’ve been served redirects, a virus, or observed sketchy or off-brand ads on a publisher’s site. To stay on top of what they’re saying, monitor social media and Google reviews and not just the customer support line. Many users take aim at businesses on social media and on internet review sites in attempts to “shame” the business into a quick response.
2. Spikes in bounce rate or decrease in session length
Since redirects are often launched early in the user’s session, it’s a good idea to check Google Analytics for all web pages. If there is a swift deviation from established patterns of the amount of time users spend on the website, or if most visitors don’t get past the main webpage, such behavior could be a sign of a problem. It’s also important to compare browsers to see if Google Chrome, Mozilla Firefox, and Safari show similar patterns.
3. Decrease in overall monetization
If Google Analytics indicates fewer visitors to the website than usual, shorter sessions, less overall traffic, and therefore a decrease in monetization, it’s a sign that there may be unwelcome activity on your site deterring users from enjoying full sessions, or from returning to the site again after a bad experience.
4. Increase in page load time
Long load times are not a sign that your site has been attacked by malware or infected by a virus, but rather a sign of latency — a common side effect of SafeFrames. Slow load times can cause users to bounce, or encourage them to navigate away before finishing the content they’re reading or viewing.
5. Partners can’t receive viewability metrics and other KPIs
DIY security tools often prevent advertisers from seeing the true value of publisher inventory. If your advertisers are not able to measure their campaigns accurately, your inventory and your site overall will lose value.
Real-time protection optimizes revenue
SafeFrames may be safer than no SafeFrames, but they don’t provide real-time protection that allows publishers to maximize their revenue.
Between IAB, Google AdSense, and DIY solutions for preventing redirects and other malvertising attacks, publishers still don’t have a clear holistic solution to cover all ad networks.
Google sets recommendations and requirements in Ad Manager, but opting into additional Google Ad Manager protections is up to the publisher and the advertiser — and bad actors will obviously never opt-in. Sandboxing requires added time and effort from the ops team to avoid harming ad functionality and performance — and it doesn’t even prevent malvertising attacks like cryptomining or ad stuffing.
Some see SafeFrames and DIY security workarounds as cost-savers, but that is short-sighted. They may require little to no extra money upfront, but the loss of traffic, lifetime users, and revenue that results from redirects and other malicious attacks through under-secured ad slots have high costs in the long term.
Real-time detection and blocking of any malicious ads, and airtight QA automation, is the only surefire ad security strategy for publishers. These methods pinpoint known threats in the ecosystem, identify new threats, and prevent the clean-up that follows an attack. Real-time monitoring and blocking, directly helps publishers improve KPIs, increase the lifetime value of their audiences, add any demand partners they want, set the floors they need, and grow their overall revenue.
Is your site getting hit with mobile redirects and other fraudulent demand? Drop us a line
