To fix this, Cloudflare is working towards a set of solutions that consolidates all SaaS connections via a single proxy, for easier monitoring, detection and response. A SaaS to SaaS proxy for everyone.

As we build this, we need feedback from the community, both data owners and SaaS platform providers. If you are interested in gaining early access, please sign up here.

SaaS platform providers, who often offer marketplaces for additional applications, store data on behalf of their customers and ultimately become the trusted guardians. As integrations with marketplace applications take place, that guardianship is put to the test. A key breach in any one of these integrations can lead to widespread data exfiltration and tampering. As more apps are added the attack surface grows larger. Security teams who work for the data owner have no ability, today, to detect and react to any potential breach.

In this post we explain the underlying technology required to make this work and help keep your data on the Internet safe.

No one disputes the value provided by SaaS applications and their integrations. Major SaaS companies implement flourishing integration ecosystems, often presented as marketplaces. For many, it has become part of their value pitch. Salesforce provides an AppExchange. Zendesk provides a marketplace. ServiceNow provides an Integration Hub. And so forth.

These provide significant value to any organisation and complex workflows. Data analysis or other tasks that are not supported natively by the SaaS vendor are easily carried out via a few clicks.

On the other hand, SaaS applications present security teams with a growing list of unknowns. Who can access this data? What security processes are put in place? And more importantly: how do we detect data leak, compromise, or other malicious intent?

Following the Salesloft breach, which compromised the data of hundreds of companies, including Cloudflare, the answers to these questions are top of mind.

There are two approaches Cloudflare is actively prototyping to address the growing security challenges SaaS applications pose, namely visibility into SaaS to SaaS connections, including anomaly detection and key management in the event of a breach. Let’s go over each of these, both relying on proxying SaaS to SaaS traffic.

Cloudflare runs one of the world’s largest reverse proxy networks. As we terminate L7 traffic, we are able to perform security-related functions including blocking malicious requests, detecting anomalies, detecting automated traffic and so forth. This is one of the main use cases customers approach us for.

Cloudflare can proxy any hostname under the customer’s control.

It is this specific ability, often referred to as “vanity”, “branded” or “custom” hostnames, that allows us to act as a front door to the SaaS vendor on behalf of a customer. Provided a marketplace app integrates via a custom domain, the data owner can choose to use Cloudflare’s new SaaS integration protection capabilities.

For a customer (Acme Corp in this example) to access, say SaaS Application, the URL needs to become saas.acme.com as that is under Acme’s control (and not acme.saas.com).

This setup allows Cloudflare to be placed in front of SaaS Corp as the customer controls the DNS hostname. By proxying traffic, Cloudflare can be the only integration entity with programmatic access to SaaS Corp's APIs and data and transparently "swap" authorisation tokens with valid ones and issue separate tokens, using key splitting, to any integrations. 

Note that in many cases, authorization and authentication flows fall outside any vanity/branded hostname. It is in fact very common for an OAuth flow to still hit the SaaS provider url oauth.saas.com. It is therefore required, in this setup, for marketplace applications to provide the ability to support vanity/branded URLs for their OAuth and similar flows, oauth.saas.acme.com in the diagram above.

Ultimately Cloudflare provides a full L7 reverse proxy for all traffic inbound/outbound to the given SaaS provider solving for the core requirements that would lessen the impact of a similar breach to the Salesloft example. Had Salesloft integrated via a Cloudflare-proxied domain, then data owners would be able to:

• Gain visibility into who or what can access data, and where it’s accessed from, in the SaaS platform. Cloudflare already provides analytics and filtering tools to identify traffic sources, including hosting locations, IPs, user agents and other tools.

• Instantly shut off access to the SaaS provider without the need to rotate credentials on the SaaS platform, as Cloudflare would be able to block access from the proxy.

• Detects anomalies in data access by observing baselines and traffic patterns. For example a change in data exfiltration traffic flows would trigger an alert.

The approach listed above assumes the end user is the company whose data is at risk. However, SaaS platforms themselves are now paying a lot of attention to marketplace applications and access patterns. From a deployment perspective, it’s actually easier to provide additional visibility to a SaaS provider as it is a standard reverse proxy deployment and we have tools designed for SaaS applications, such as Cloudflare for SaaS.

This deployment model allows Cloudflare to proxy all traffic to the SaaS vendor, including to all API endpoints therefore gaining visibility into any SaaS to SaaS connections. As part of this, we are building improvements to our API Shield solution to provide SaaS security teams with additional controls:

• Token / session logging: Ability to keep track of OAuth tokens and provide session logs for audit purposes.

• Session anomaly detection: Ability to warn when a given OAuth (or other session) shows anomalous behavior.

• Token / session replacement: Ability to substitute SaaS-generated tokens with Cloudflare-generated tokens to allow for fast rotation and access lock down.

The SaaS vendor may of course expose some of the affordances to their end customer as part of their dashboard.

Both deployment approaches described above rely on our ability to control access without storing complete credentials. While we already store SSL/TLS private keys for millions of web applications, storing complete SaaS bearer tokens would create an additional security burden. To solve this, and enable the token swapping and instant revocation capabilities mentioned above, we use key splitting.

Key splitting cryptographically divides bearer tokens into two mathematically interdependent fragments called Part A and Part B. Part A goes to the fourth-party integration (like Drift or Zapier) while Part B stays in Cloudflare's edge storage. Part A is just random noise that won't authenticate to Salesforce or any SaaS platform expecting complete tokens, so neither fragment is usable alone.

This creates an un-bypassable control point. Integrations cannot make API calls without going through Cloudflare's proxy because they only possess Part A. When an integration needs to access data, it must present Part A to our edge where we retrieve Part B, reconstruct the token in memory for microseconds, forward the authenticated request, and then immediately clear the token. This makes sure that the complete bearer token never exists in any database or log.

This forced cooperation means every API call flows through Cloudflare where we can monitor for anomalies, delete Part B to instantly revoke access (transforming incident response from hours to seconds), and maintain complete audit trails. Even more importantly, this approach minimizes our burden of storing sensitive credentials since a breach of our systems wouldn't yield usable tokens.

If attackers compromise the integration and steal Part A, or somehow breach Cloudflare's storage and obtain Part B, neither fragment can authenticate on its own. This fundamentally changes the security model from protecting complete tokens to managing split fragments that are individually worthless. It also gives security teams unprecedented visibility and control over how their data is accessed across third-party integrations.

We are excited to develop solutions mentioned above to give better control and visibility around data stored in SaaS environments, or more generally, outside a customer’s network.

If you are a company worried about this risk, and would like to be notified to take part in our early access, please sign up here.

If you are a SaaS vendor who would like to provide feedback and take part in developing better API security tooling for third party integrations towards your platform, sign up here.

We are looking forward to helping you get better control of your data in SaaS to SaaS environments.

We’re excited to announce that we’re going to be adding SSL.com as a certificate authority that Cloudflare customers can use. This means that Cloudflare customers that are currently relying on Entrust as a CA and uploading their certificate manually to Cloudflare will now be able to rely on Cloudflare’s certificate management pipeline for automatic issuance and renewal of SSL.com certificates. 

With great power comes great responsibility Every publicly trusted certificate authority (CA) is responsible for maintaining a high standard of security and compliance to ensure that the certificates they issue are trustworthy. The security of millions of websites and applications relies on a CA’s commitment to these standards, which are set by the CA/Browser Forum, the governing body that defines the baseline requirements for certificate authorities. These standards include rules regarding certificate issuance, validation, and revocation, all designed to secure the data transferred over the Internet. 

However, as with all complex software systems, it’s inevitable that bugs or issues may arise, leading to the mis-issuance of certificates. Improperly issued certificates pose a significant risk to Internet security, as they can be exploited by malicious actors to impersonate legitimate websites and intercept sensitive data. 

To mitigate such risk, publicly trusted CAs are required to communicate issues as soon as they are discovered, so that domain owners can replace the compromised certificates immediately. Once the issue is communicated, CAs must revoke the mis-issued certificates within 5 days to signal to browsers and clients that the compromised certificate should no longer be trusted. This level of transparency and urgency around the revocation process is essential for minimizing the risk posed by compromised certificates. 

Why Chrome and Mozilla are distrusting Entrust The decision made by Chrome and Mozilla to distrust Entrust’s public TLS certificates stems from concerns regarding Entrust’s incident response and remediation process. In several instances, Entrust failed to report critical issues and did not revoke certificates in a timely manner. The pattern of delayed action has eroded the browsers’ confidence in Entrust’s ability to act quickly and transparently, which is crucial for maintaining trust as a CA. 

Google and Mozilla cited the ongoing lack of transparency and urgency in addressing mis-issuances as the primary reason for their distrust decision. Google specifically pointed out that over the past 6 years, Entrust has shown a "pattern of compliance failures" and failed to make the "tangible, measurable progress" necessary to restore trust. Mozilla echoed these concerns, emphasizing the importance of holding Entrust accountable to ensure the integrity and security of the public Internet. 

Entrust’s response to the distrust announcement  In response to the distrust announcement from Chrome and Mozilla, Entrust has taken proactive steps to ensure continuity for their customers. To prevent service disruption, Entrust has announced that they are partnering with SSL.com, a CA that’s trusted by all major browsers, including Chrome and Mozilla, to issue certificates for their customers. By issuing certificates from SSL.com’s roots, Entrust aims to provide a seamless transition for their customers, ensuring that they can continue to obtain certificates that are recognized and trusted by the browsers their users rely on. 

In addition to their partnership with SSL.com, Entrust stated that they are working on a number of improvements, including changes to their organizational structure, revisions to their incident response process and policies, and a push towards automation to ensure compliant certificate issuances. 

Now available: SSL.com as a certificate authority for Advanced Certificate Manager and SSL for SaaS certificates We’re excited to announce that customers using Advanced Certificate Manager will now be able to select SSL.com as a certificate authority for Advanced certificates and Total TLS certificates. Once the certificate is issued, Cloudflare will handle all future renewals on your behalf. 

By default, Cloudflare will issue SSL.com certificates with a 90 day validity period. However, customers using Advanced Certificate Manager will have the option to set a custom validity period (14, 30, or 90 days) for their SSL.com certificates. In addition, Enterprise customers will have the option to obtain 1-year SSL.com certificates. Every SSL.com certificate order will include 1 RSA and 1 ECDSA certificate.

Note: We are gradually rolling this out and customers should see the CA become available to them through the end of September and into October. 

If you’re using Cloudflare as your DNS provider, there are no additional steps for you to take to get the certificate issued. Cloudflare will validate the ownership of the domain on your behalf to get your SSL.com certificate issued and renewed. 

If you’re using an external DNS provider and have wildcard hostnames on your certificates, DNS based validation will need to be used, which means that you’ll need to add TXT DCV tokens at your DNS provider in order to get the certificate issued. With SSL.com, two tokens are returned for every hostname on the certificate. This is because SSL.com uses different tokens for the RSA and ECDSA certificates. To reduce the overhead around certificate management, we recommend setting up DCV Delegation to allow Cloudflare to place domain control validation (DCV) tokens on your behalf. Once DCV Delegation is set up, Cloudflare will automatically issue, renew, and deploy all future certificates for you. 

Advanced Certificates: selecting SSL.com as a CA through the UI or API Customers can select SSL.com as a CA through the UI or through the Advanced Certificate API endpoint by specifying “ssl_com” in the certificate_authority parameter. 

If you’d like to use SSL.com as a CA for an advanced certificate, you can select “SSL.com” as your CA when creating a new Advanced certificate order. 

If you’d like to use SSL.com as a CA for all of your certificates, we recommend setting your Total TLS CA to SSL.com. This will issue an individual certificate for each of your proxied hostname from the CA. 

Note: Total TLS is a feature that’s only available to customers that are using Cloudflare as their DNS provider. 

SSL for SaaS: selecting SSL.com as a CA through the UI or API Enterprise customers can select SSL.com as a CA through the custom hostname creation UI or through the Custom Hostnames API endpoint by specifying “ssl_com” in the certificate_authority parameter. 

All custom hostname certificates issued from SSL.com will have a 90 day validity period. If you have wildcard support enabled for custom hostnames, we recommend using DCV Delegation to ensure that all certificate issuances and renewals are automatic.  

Cloudflare customers that use Entrust as their CA are required to manually handle all certificate issuances and renewals. Since Cloudflare does not directly integrate with Entrust, customers have to get their certificates issued directly from the CA and upload them to Cloudflare as custom certificates. Once these certificates come up for renewal, customers have to repeat this manual process and upload the renewed certificates to Cloudflare before the expiration date. 

Manually managing your certificate’s lifecycle is a time-consuming and error prone process. With certificate lifetimes decreasing from 1 year to 90 days, this cycle needs to be repeated more frequently by the domain owner. 

As Entrust transitions to issuing certificates from SSL.com roots, this manual management process will remain unless customers switch to Cloudflare’s managed certificate pipeline. By making this switch, you can continue to receive SSL.com certificates without the hassle of manual management — Cloudflare will handle all issuances and renewals for you!

In early October, we will be reaching out to customers who have uploaded Entrust certificates to Cloudflare to recommend migrating to our managed pipeline for SSL.com certificate issuances, simplifying your certificate management process. 

If you’re ready to make the transition today, simply go to the SSL/TLS tab in your Cloudflare dashboard, click “Order Advanced Certificate”, and select “SSL.com” as your certificate authority. Once your new SSL.com certificate is issued, you can either remove your Entrust certificate or simply let it expire. Cloudflare will seamlessly transition to serving the managed SSL.com certificate before the Entrust certificate expires, ensuring zero downtime during the switch. 

As part of Security Week, two new integrations are coming to Cloudflare CASB, one for Atlassian Confluence and the other for Atlassian Jira.

We’re excited to launch support for these two new SaaS applications (in addition to those we already support) given the reliance that we’ve seen organizations from around the world place in them for streamlined, end-to-end project management.

Let’s dive into what Cloudflare Zero Trust customers can expect from these new integrations.

First, a quick recap. CASB, or Cloud Access Security Broker, is one of Cloudflare’s newer offerings, released last September to provide security operators - CISOs and security engineers - clear visibility and administrative control over the security of their SaaS apps.

Whether it’s Google Workspace, Microsoft 365, Slack, Salesforce, Box, GitHub, or Atlassian (whew!), CASB can easily connect and scan these apps for critical security issues, and provide users an exhaustive list of identified problems, organized for triage.

Over time, Atlassian Confluence has become the go-to collaboration platform for teams to create, organize, and share content, such as documents, notes, and meeting minutes. However, from a security perspective, Confluence's flexibility and wide compatibility with third-party applications can pose a security risk if not properly configured and monitored.

With this new integration, IT and security teams can begin scanning for Atlassian- and Confluence-specific security issues that may be leaving sensitive corporate data at risk. Customers of CASB using Confluence Cloud can expect to identify issues like publicly shared content, unauthorized access, and other vulnerabilities that could be exploited by bad actors.

By providing this additional layer of SaaS security, Cloudflare CASB can help organizations better protect their sensitive data while still leveraging the collaborative power of Confluence.

A mainstay project management tool used to track tasks, issues, and progress on projects, Atlassian Jira has become an essential part of the software development process for teams of all sizes. At the same time, this also means that Jira has become a rich target for those looking to exploit and gain access to sensitive data.

With Cloudflare CASB, security teams can now easily identify security issues that could leave employees and sensitive business data vulnerable to compromise. Compatible with Jira Cloud accounts, Identified issues can range from flagging user and third-party app access issues, such as account misuse and users not following best practices, to identification of files that could be potentially overshared and worth deeper investigation.

By providing security admins with a single view to see security issues across their entire SaaS footprint, now including Jira and Confluence, Cloudflare CASB makes it easier for security teams to stay up-to-date with potential security risks.

With the addition of Jira and Confluence to the growing list of CASB integrations, we’re making our products as widely compatible as possible so that organizations can continue placing their trust and confidence in us to help keep them secure.

Today, Cloudflare CASB supports integrations with Google Workspace, Microsoft 365, Slack, Salesforce, Box, GitHub, Jira, and Confluence, with a growing list of other critical applications on their way, so if there’s one in particular you’d like to see soon, let us know!

For those not already using Cloudflare Zero Trust, don’t hesitate to get started today - see the platform yourself with 50 free seats by signing up here, then get in touch with our team here to learn more about how Cloudflare CASB can help your organization lock down its SaaS apps.

Today, we’re sharing the release of two new SaaS integrations for Cloudflare CASB - Salesforce and Box - in order to help CIOs, IT leaders, and security admins swiftly identify looming security issues present across the exact type of tools housing this business-critical data.

Released in September, Cloudflare’s API CASB has already proven to organizations from around the world that security risks - like insecure settings and inappropriate file sharing - can often exist across the friendly SaaS apps we all know and love, and indeed pose a threat. By giving operators a comprehensive view of the issues plaguing their SaaS environments, Cloudflare CASB has allowed them to effortlessly remediate problems in a timely manner before they can be leveraged against them.

But as both we and other forward-thinking administrators have come to realize, it’s not always Microsoft 365, Google Workspace, and business chat tools like Slack that contain an organization’s most sensitive information.

The first Software-as-a-Service. Salesforce, the sprawling, intricate, hard-to-contain Customer Relationship Management (CRM) platform, gives workforces a flexible hub from which they can do just as the software describes: manage customer relationships. Whether it be tracking deals and selling opportunities, managing customer conversations, or storing contractual agreements, Salesforce has truly become the ubiquitous solution for organizations looking for a way to manage every customer-facing interaction they have.

This reliance, however, also makes Salesforce a business data goldmine for bad actors.

With CASB’s new integration for Salesforce, IT and security operators will be able to quickly connect their environments and scan them for the kind of issues putting their sensitive business data at risk. Spot uploaded files that have been shared publicly with anyone who has the link. Identify default permissions that give employees access to records that should be need-to-know only. You can even see employees who are sending out emails as other Salesforce users!

Using this new integration, we’re excited to help close the security visibility gap for yet another SaaS app serving as the lifeblood for teams out in the field making business happen.

Box is the leading Content Cloud that enables organizations to accelerate business processes, power workplace collaboration, and protect their most valuable information, all while working with a best-of-breed enterprise IT stack like Cloudflare.

A platform used to store everything - from contracts and financials to product roadmaps and employee records - Box has given collaborative organizations a single place to convene and share information that, in a growing remote-first world, has no better place to be stored.

So where are disgruntled employees and people with malicious intent going to look when they want to unveil private business files?

With Cloudflare CASB’s new integration for Box, security and IT teams alike can now link their admin accounts and scan them for under-the-radar security issues leaving them prone to compromise and data exfiltration. In addition to Box’s built-in content and collaboration security, Cloudflare CASB gives you another added layer of protection where you can catch files and folders shared publicly or with users outside your organization. By providing security admins with a single view to see employees who aren’t following security policies, we make it harder for bad actors to get inside and do damage.

With Cloudflare’s status as an official Box Technology Partner, we’re looking forward to offering both Cloudflare and Box users a robust, yet easy-to-use toolset that can help stop pressing, real-world data security incidents right in their tracks.

“Organizations today need products that are inherently secure to support employees working from anywhere,” said Areg Alimian, Head of Security Products at Box. “At Box, we continuously strive to improve our integrations with third-party apps so that it’s easier than ever for customers to use Box alongside best-in-class solutions. With today’s integration with Cloudflare CASB, we enable our joint customers to have a single pane of glass view allowing them to consistently enforce security policies and protect leakage of sensitive information across all their apps.”

Salesforce and Box are certainly not the only SaaS applications managing this type of sensitive organizational data. At Cloudflare, we strive to make our products as widely compatible as possible so that organizations can continue to place their trust and confidence in us to help keep them secure.

Today, Cloudflare CASB supports integrations with Google Workspace, Microsoft 365, Slack, GitHub, Salesforce, and Box, with a growing list of other critical applications on their way, so if there’s one in particular you’d like to see soon, let us know!

For those not already using Cloudflare Zero Trust, don’t hesitate to get started today - see the platform yourself with 50 free seats by signing up here, then get in touch with our team here to learn more about how Cloudflare CASB can help your organization lock down its SaaS apps.

The Software as a Service (SaaS) model has changed the way we work – 80% of businesses use at least one SaaS application. Instead of investing in building proprietary software or installing and maintaining on-prem licensed software, SaaS vendors provide businesses with out-of-the-box solutions.

SaaS has many benefits over the traditional software model: cost savings, continuous updates and scalability, to name a few. However, any managed solution comes with trade-offs. As a business, one of the biggest challenges in adopting SaaS tooling is loss of customization. Not every business uses software in the same way and as you grow as a SaaS company it’s not long until you get customers saying “if only I could do X”.

Enter Workers for Platforms – Cloudflare's serverless functions offering for SaaS businesses. With Workers for Platforms, your customers can build custom logic to meet their requirements right into your application.

We’re excited to announce that Workers for Platforms is now in GA for all Enterprise customers! If you’re an existing customer, reach out to your Customer Success Manager (CSM) to get access. For new customers, fill out our contact form to get started.

As a SaaS business invested in capturing the widest market, you want to build a universal solution that can be used by customers of different sizes, in various industries and regions. However, every one of your customers has a unique set of tools and vendors and best practices. A generalized platform doesn’t always meet their needs.

For SaaS companies, once you get in the business of creating customizations yourself, it can be hard to keep up with seemingly never ending requests. You want your engineering teams to focus on building out your core business instead of building and maintaining custom solutions for each of your customer’s use cases.

With Workers for Platforms, you can give your customers the ability to write code that customizes your software. This gives your customers the flexibility to meet their exact use case while also freeing up internal engineering time  – it’s a win-win!

Workers is Cloudflare’s serverless execution environment that runs your code on Cloudflare’s global network. Workers is lightning fast and scalable; running at data centers in more than 275 cities globally and serving requests from as close as possible to the end user. Workers for Platforms extends the power of Workers to our customer’s developers!

Dispatch Worker: As a platform customer, you want to have full control over how end developer code fits in with your APIs. A Dispatch Worker is written by our platform customers to run their own logic before dispatching (aka routing) to Workers written by end developers. In addition to routing, it can be used to run authentication, create boilerplate functions and sanitize responses.

User Workers: User Workers are written by end developers, that is, our customers’ developers. End developers can deploy User Workers to script automated actions, create integrations or modify response payload to return custom content. Unlike self-managed Function-as-a-Service (FaaS) options, with Workers for Platforms, end developers don’t need to worry about setting up and maintaining their code on any 3rd party platform. All they need to do is upload their code and you – or rather Cloudflare – takes care of the rest.

Unlimited Scripts: Yes, you read that correctly! With hundreds-plus end developers, the existing 100 script limit for Workers won’t cut it for Workers for Platforms customers. Some of our Workers for Platforms customers even deploy a new script each time their end developers make a change to their code in order to maintain version control and to easily revert to a previous state if a bug is deployed.

Dynamic Dispatch Namespaces: If you’ve used Workers before, you may be familiar with a feature we released earlier this year, Service Bindings. Service Bindings are a way for two Workers to communicate with each other. They allow developers to break up their applications into modules that can be chained together. Service Bindings explicitly link two Workers together, and they’re meant for use cases where you know exactly which Workers need to communicate with each other.

Service Bindings don’t work in the Workers for Platforms model because User Workers are uploaded ad hoc. Dynamic Dispatch Namespaces is our solution to this! A Dispatch Namespace is composed of a collection of User Workers. With Dispatch Namespaces, a Dispatch Worker can be used to call any User Worker in a namespace (similar to how Service Bindings work) but without needing to explicitly pre-define the relationship.

Read more about how to use these features below!

Dispatch Workers are the entry point for requests to Workers in a Dispatch Namespace. The Dispatch Worker can be used to run any functions ahead of User Workers. They can make a request to any User Workers in the Dispatch Namespace, and they ultimately handle the routing to User Workers.

Dispatch Workers are created the same way as a regular Worker, except they need a Dispatch Namespace binding in the project’s wrangler.toml configuration file.

[[dispatch_namespaces]]
binding = "dispatcher"
namespace = "api-prod"

In the example below, this Dispatch Worker reads the subdomain from the path and calls the appropriate User Worker. Alternatively you can use KV, D1 or your data store of choice to map identifying parameters from an incoming request to a User Worker.

export default {
 async fetch(request, env) {
   try {
       // parse the URL, read the subdomain
       let worker_name = new URL(request.url).host.split('.')[0]
       let user_worker = env.dispatcher.get(worker_name)
       return user_worker.fetch(request)
   } catch (e) {
       if (e.message == 'Error: Worker not found.') {
           // we tried to get a worker that doesn't exist in our dispatch namespace
           return new Response('', {status: 404})
       }
       // this could be any other exception from `fetch()` *or* an exception
       // thrown by the called worker (e.g. if the dispatched worker has
       // `throw MyException()`, you could check for that here).
       return new Response(e.message, {status: 500})
   }
 }

}

User Workers must be uploaded to a Dispatch Namespace through the Cloudflare API (wrangler support coming soon!). This code snippet below uses a simple HTML form to take in a script and customer id and then uploads it to the Dispatch Namespace.

export default {
 async fetch(request: Request) {
   try {
     // on form submit
     if (request.method === "POST"){
       const str = JSON.stringify(await request.json())
       const upload_obj = JSON.parse(str)
       await upload(upload_obj.customerID, upload_obj.script)
   }
   //render form
     return new Response (html, {
       headers: {
         "Content-Type": "text/html"
       }
     })
   } catch (e) {
       // form error
       return new Response(e.message, {status: 500})
   }
 }
}

async function upload(customerID:string, script:string){
 const scriptName = customerID;
 const scriptContent = script;
 const accountId = "<ACCOUNT_ID>";
 const dispatchNamespace = "api-prod";
 const url = `https://api.cloudflare.com/client/v4/accounts/${accountId}/workers/dispatch/namespaces/${dispatchNamespace}/scripts/${scriptName}`;
 // construct and send request
 const response = await fetch(url, {
   method: "PUT",
   body: scriptContent,
   headers: {
     "Content-Type": "application/javascript",
     "X-Auth-Email": "<EMAIL>",
     "X-Auth-Key": "<API_KEY>"
   }
 });

 const result = (await response.json());
 if (response.status != 200) {
   throw new Error(`Upload error`);
 }
}

It’s that simple. With Dispatch Namespaces and Dispatch Workers, we’re giving you the building blocks to customize your SaaS applications. Along with the Platforms APIs, we’re also releasing a Workers for Platforms UI on the Cloudflare dashboard where you can view your Dispatch Namespaces, search scripts and view analytics for User Workers.

To view an end to end example, check out our Workers for Platforms example application.

We’re releasing Workers for Platforms to all Cloudflare Enterprise customers. If you’re interested, reach out to your Customer Success Manager (CSM) to get access. To get started, take a look at our Workers for Platforms starter project and developer documentation.

We also have plans to release this down to the Workers Paid plan. Stay tuned on the Cloudflare Discord (channel name: workers-for-platforms) for updates.

We’ve heard lots of great feature requests from our early Workers for Platforms customers. Here’s a preview of what’s coming next on the roadmap:

• Fine-grained controls over User Workers: custom script limits, allowlist/blocklist for fetch requests

• GraphQL and Logs: Metrics for User Workers by tag

• Plug and play Platform Development Kit

• Tighter integration with Cloudflare for SaaS custom domains

If you have specific feature requests in mind, please reach out to your CSM or get in touch through the Discord!

It’s GA Week here at Cloudflare, meaning some of our latest and greatest endeavors are here and ready to be put in the hands of Cloudflare customers around the world. One of those releases is Cloudflare’s API-driven Cloud Access Security Broker, or CASB, one of the newest additions to our Zero Trust platform.

Starting today, IT and security administrators can begin using Cloudflare CASB to connect, scan, and monitor their third-party SaaS applications for a wide variety of security issues - all in just a few clicks.

Whether it’s auditing Google Drive for data exposure and file oversharing, checking Microsoft 365 for misconfigurations and insecure settings, or reviewing third-party access for Shadow IT, CASB is now here to help organizations establish a direct line of sight into their SaaS app security and DLP posture.

Try to think of a business or organization that uses fewer than 10 SaaS applications. Hard, isn’t it?

It’s 2022, and by now, most of us have noticed the trend of mass SaaS adoption balloon over recent years, with some organizations utilizing hundreds of third-party services across a slew of internal functions. Google Workspace and Microsoft 365 for business collaboration. Slack and Teams for communication. Salesforce for customer management, GitHub for version control… the list goes on and on and on.

And while the average employee might see these products as simply tools used in their day-to-day work, the reality is much starker than that. Inside these services lie some of an organization’s most precious, sensitive, business-critical data - something IT and security teams don’t take lightly and strive to protect at all costs.

But there hasn’t been a great way for these teams to ensure their data and the applications that contain it are kept secure. Go user by user, file by file, SaaS app by SaaS app and review everything for what could be potentially problematic? For most organizations, that’s just simply not realistic.

So, doing what Cloudflare does best, how are we helping our users get a grip on this wave of growing security risk in an intuitive and manageable way?

Connect your most critical SaaS applications in just minutes and clicks

It all starts with a simple integration process, connecting your favorite SaaS applications to Cloudflare CASB in just a few clicks. Once connected, you’ll instantly begin to see Findings - or identified security issues - appear on your CASB home page.

CASB utilizes each vendor’s API to scan and identify a range of application-specific security issues that span several domains of information security, including misconfigurations and insecure settings, file sharing security, Shadow IT, best practices not being followed, and more.

Today CASB supports integrations with Google Workspace, Microsoft 365, Slack, and GitHub, with a growing list of other critical applications not far behind. Have a SaaS app you want to see next? Let us know!

See how all your files have been shared

One of the easiest ways for employees to accidentally expose internal information is usually with just the flick of a switch - changing a sharing setting to Share this file to anyone with the link.

Cloudflare CASB provides users an exhaustive list of files that have questionable, often insecure, sharing settings, giving them a fast and reliable way to address low-hanging fruit exposures and get ahead of data protection incidents.

Identify insecure settings and bad practices

How we configure our SaaS apps dictates how they keep our data secure. Would you know if that one important GitHub repository had its visibility changed from Private to Public overnight? And why does one of our IT admins not have 2FA enabled on their account?

With Cloudflare CASB, users can now see those issues in just a few clicks and prioritize misconfigurations that might not expose just one file, but the entirety of them across your organization’s SaaS footprint.

Discover third-party apps with shadowy permissions

With the advent of frictionless product signups comes the rise of third-party applications that have breezed past approval processes and internal security reviews to lay claim to data and other sensitive resources. You guessed it, we’re talking about Shadow IT.

Cloudflare CASB adds a layer of access visibility beyond what traditional network-based Shadow IT discovery tools (like Cloudflare Gateway) can accomplish on their own, providing a detailed list of access that’s been granted to third-party services via those easy Sign in with Google buttons.

While we’re here to talk about CASB, it would be remiss if we didn’t acknowledge how CASB is only one piece of the puzzle in the wider context of Zero Trust.

Zero Trust is all about broad security coverage and simple interconnectivity with how employees access, navigate, and leverage the complex systems and services needed to operate every day. Where Cloudflare Access and Gateway have provided users with granular access control and visibility into how employees traverse systems, and where Browser Isolation and our new in-line DLP offering protect users from malicious sites and limit sensitive data flying over the wire, CASB adds coverage for one of enterprise security’s final frontiers: visibility into data at-rest, who/what has access to it, and the practices that make it easier or harder for someone to access it inappropriately.

As we’ve found through CASB’s beta program over the last few months, SaaS sprawl and misuse compounds with time - we’ve already identified more than five million potential security issues across beta users, with some organizations seeing several thousand files flagged as needing a sharing setting review.

So don’t hesitate to get started on your SaaS app wrangling and cleanup journey; it’s easier than you might think.

To get started, create a free Zero Trust account to try it out with 50 free seats, and then get in touch with our team here to learn more about how Cloudflare CASB can help at your organization. We can’t wait to hear what you think.

As a SaaS provider, you’re juggling many challenges while building your application, whether it’s custom domain support, protection from attacks, or maintaining an origin server. In 2021, we were proud to announce Cloudflare for SaaS for Everyone, which allows anyone to use Cloudflare to cover those challenges, so they can focus on other aspects of their business. This product has a variety of potential implementations; now, we are excited to announce a new section in our Developer Docs specifically devoted to Cloudflare for SaaS documentation to allow you take full advantage of its product suite.

You may remember, from our October 2021 blog post, all the ways that Cloudflare provides solutions for SaaS providers:

• Set up an origin server

• Encrypt your customers’ traffic

• Keep your customers online

• Boost the performance of global customers

• Support custom domains

• Protect against attacks and bots

• Scale for growth

• Provide insights and analytics

However, we received feedback from customers indicating confusion around actually using the capabilities of Cloudflare for SaaS because there are so many features! With the existing documentation, it wasn’t 100% clear how to enhance security and performance, or how to support custom domains. Now, we want to show customers how to use Cloudflare for SaaS to its full potential by including more product integrations in the docs, as opposed to only focusing on the SSL/TLS piece.

Cloudflare for SaaS can be overwhelming with so many possible add-ons and configurations. That’s why the new docs are organized into six main categories, housing a number of new, detailed guides (for example, WAF for SaaS and Regional Services for SaaS):

Once you get your SaaS application up and running with the Get Started page, you can find which configurations are best suited to your needs based on your priorities as a provider. Even if you aren’t sure what your goals are, this setup outlines the possibilities much more clearly through a number of new documents and product guides such as:

• Regional Services for SaaS

• Querying HTTP events by hostname with GraphQL

• Migrating custom hostnames

Instead of pondering over vague subsection titles, you can peruse with purpose in mind. The advantages and possibilities of Cloudflare for SaaS are highlighted instead of hidden.

This setup facilitates configurations much more easily to meet your goals as a SaaS provider.

For example, consider performance. Previously, there was no documentation surrounding reduced latency for SaaS providers. Now, the Performance section explains the automatic benefits to your performance by onboarding with Cloudflare for SaaS. Additionally, it offers three options of how to reduce latency even further through brand-new docs:

• Early Hints for SaaS

• Cache for SaaS

• Argo Smart Routing for SaaS

Similarly, the new organization offers WAF for SaaS as a previously hidden security solution, extending providers the ability to enable automatic protection from vulnerabilities and the flexibility to create custom rules. This is conveniently accompanied by a step-by-step tutorial using Cloudflare Managed Rulesets.

While this transition represents an improvement in the Cloudflare for SaaS docs, we’re going to expand its accessibility even more. Some tutorials, such as our Managed Ruleset Tutorial, are already live within the tile. However, more step-by-step guides for Cloudflare for SaaS products and add-ons will further enable our customers to take full advantage of the available product suite. In particular, keep an eye out for expanding documentation around using Workers for Platforms.

Visit the new Cloudflare for SaaS tile to see the updates. If you are a SaaS provider interested in extending Cloudflare benefits to your customers through Cloudflare for SaaS, visit our Cloudflare for SaaS overview and our Plans page.

When you connect to a website, you should see a lock icon in the address bar — that’s your browser telling you that you’re connecting to a website over a secure connection and that the website has a valid public TLS certificate. TLS certificates keep Internet traffic encrypted using a public/private key pair to encrypt and decrypt traffic. They also provide authentication, proving to clients that they are connecting to the correct server.

To make a secure connection, a TLS handshake needs to take place. During the handshake, the client and the server exchange cryptographic keys, the client authenticates the identity of the server, and both the client and the server generate session keys that are later used to encrypt traffic.

A TLS handshake looks like this:

In a TLS handshake, the client always validates the certificate that is served by the server to make sure that it's sending requests to the right destination. In the same way that the client needs to authenticate the identity of the server, sometimes the server needs to authenticate the client — to ensure that only authorized clients are sending requests to the server.

Let’s say that you’re managing a few services: service A writes information to a database. This database is absolutely crucial and should only have entries submitted by service A. Now, what if you have a bug in your system and service B accidentally makes a write call to the database?

You need something that checks whether a service is authorized to make calls to your database — like a bouncer. A bouncer has a VIP list — they can check people’s IDs against the list to see whether they’re allowed to enter a venue. Servers can use a similar model, one that uses TLS certificates as a form of ID.

In the same way that a bouncer has a VIP list, a server can have a Certificate Authority (CA) Root from which they issue certificates. Certificates issued from the CA Root are then provisioned onto clients. These client certificates can then be used to identify and authorize the client. As long as a client presents a valid certificate — one that the server can validate against the Root CA, it's allowed to make requests. If a client doesn’t present a client certificate (isn’t on the VIP list) or presents an unauthorized client certificate, then the server can choose to reject the request. This process of validating client and server certificates is called mutual TLS authentication (mTLS) and is done during the TLS handshake.

When mTLS isn’t used, only the server is responsible for presenting a certificate, which the client verifies. With mTLS, both the client and the server present and validate one another’s certificates, pictured below.

A few years ago, we added mTLS support to our Access product, allowing customers to enable a Zero Trust policy on their applications. Access customers can deploy a policy that dictates that all clients must present a valid certificate when making a request. That means that requests made without a valid certificate — usually from unauthorized clients — will be blocked, adding an extra layer of protection. Cloudflare has allowed customers to configure mTLS on their Cloudflare domains by setting up Access policies. The only caveat was that to use this feature, you had to be the owner of the domain. Now, what if you’re not the owner of a domain, but you do manage that domain’s origin? This is the case for a large base of our customers, the SaaS providers that extend their services to their customers’ domains that they do not own.

Cloudflare for SaaS enables SaaS providers to extend the benefits of the Cloudflare network to their customers’ domains. These domains are not owned by the SaaS provider, but they do use the SaaS provider’s service, routing traffic back to the SaaS provider’s origin.

By doing this, SaaS providers take on the responsibility of providing their customers with the highest uptime, lightning fast performance, and unparalleled security — something they can easily extend to their customers through Cloudflare.

Cloudflare for SaaS actually started out as SSL for SaaS. We built SSL for SaaS to give SaaS providers the ability to issue TLS certificates for their customers, keeping the SaaS provider’s customers safe and secure.

Since then, our SaaS customers have come to us with a new request: extend the mTLS support that we built out for our direct customers, but to their customers.

As a SaaS provider, there’s a wide range of services that you can provide. Some of these services require higher security controls than others.

Let’s say that the SaaS solution that you’re building is a payment processor. Each customer gets its own API endpoint that their users send requests to, for example, pay.<business_name>.com. As a payment processor, you don’t want any client or device to make requests to your service, instead you only want authorized devices to do so — mTLS does exactly that.

As the SaaS provider, you can configure a Root CA for each of your customers’ API endpoints. Then, have each Root CA issue client certificates that will be installed on authorized devices. Once the client certificates have been installed, all that is left is enforcing a check for valid certificates.

To recap, by doing this, as a SaaS provider, your customers can now ensure that requests bound for their payment processing API endpoint only come from valid devices. In addition, by deploying individual Root CAs for each customer, you also prevent clients that are authorized to make requests to one customers’ API endpoint from making requests to another customers’ API endpoint when they are not authorized to do so.

As a SaaS provider, configure Cloudflare for SaaS and add your customer’s domains as Custom Hostnames. Then, in the Cloudflare for Teams dashboard, add mTLS authentication with a few clicks.

This feature is currently in Beta and is available for Enterprise customers to use. If you have any feedback, please let your Account Team know.

Last month we introduced Cloudflare’s new API–driven Cloud Access Security Broker (CASB) via the acquisition of Vectrix. As a quick recap, Cloudflare’s CASB helps IT and security teams detect security issues in and across their SaaS applications. We look at both data and users in SaaS apps to alert teams to issues ranging from unauthorized user access and file exposure to misconfigurations and shadow IT.

I’m excited to share two updates since we announced the introduction of CASB functionality to Cloudflare Zero Trust. First, we’ve heard from Cloudflare customers who cannot wait to deploy the CASB and want to use it in more depth. Today, we’re outlining what we’re building next, based on that feedback, to give you a preview of what you can expect. Second, we’re opening the sign-up for our beta, and I’m going to walk through what will be available to new users as they are invited from the waitlist.

The vision for Cloudflare’s API–driven CASB is to provide IT and security owners an easy-to-use, one-stop shop to protect the security of their data and users across their fleet of SaaS tools. Our goal is to make sure any IT or security admin can go from creating a Zero Trust account for the first time to protecting what matters most in minutes.

Beyond that immediate level of visibility, we know the problems discovered by IT and security administrators still require time to find, understand, and resolve. We’re introducing three new features to the core CASB platform in the coming months to address each of those challenges.

First, what are integrations? Integrations are what we call the method to grant permissions and connect SaaS applications (via API) to CASB for security scanning and management. Generally speaking, integrations are done following an OAuth 2.0 flow, however this varies between third-party SaaS apps. Aligning to our goal, we’ll always make sure that integration set up flows are as simple as possible and can be done in minutes.

As with most security strategies, protecting your most critical assets first becomes the priority. Integrations with Google Workspace and GitHub will be available in beta (request access here). We’ll soon follow with integrations to Zoom, Slack, and Okta before adding services like Microsoft 365 and Salesforce later this year. Working closely with customers will drive which applications we integrate with next.

On top of integrations, managing the various assets, or “digital nouns” like users, data, folders, repos, meetings, calendars, files, settings, recordings, etc. across services is tricky to say the least. Spreadsheets are hard to manage for tracking who has access to what or what files have been shared with whom.

This isn’t efficient and is ripe for human error. CASB SaaS asset management allows IT and security teams to view all of their data settings and user activity around said data from a single dashboard. Quickly being able to answer questions like; “did we disable the account for a user across these six services?” becomes a quick task instead of logging into each service and addressing individually.

Detect, prevent, and fix. With detailed SaaS remediation guides, IT administrators can assign and tackle issues with the right team. By arming teams with what they need to know in context, it makes preventing issues from happening again seamless. In situations where action should be taken straight away, automated SaaS workflows provide the ability to solve SaaS security issues in one click. Need to remove sharing permissions from that file in OneDrive? A remediation button allows for action from anywhere, anytime.

Combining products across the Zero Trust platform means solving complex problems through one seamless experience. Starting with the power of Gateway and CASB, customers will be able to take immediate action to wrangle in Shadow IT. In just a few clicks, a detected unauthorized SaaS application from the Gateway shadow IT report can go from being the wild west to a sanctioned and secure one with a CASB integration. This is just one example to highlight the many solutions we’re excited about that can be solved with the Zero Trust platform.

In the CASB beta you can deploy popular integrations like Google Workspace on day one. You’ll also get direct access to our Product team to help shape what comes next. We’re excited to work closely with a number of early customers to align on which integrations and features matter most to them.

Right now we’re working on making the out-of-band CASB product a seamless part of the Zero Trust platform. We'll be sending out the first wave of beta invitations early next month – you can request access here.

We have some big ideas of what the CASB product can and will do. While this post highlights some exciting things to come, you can get started right now with Cloudflare’s Zero Trust platform by signing up here.

Some of the largest Software-as-a-Service (SaaS) providers use Cloudflare as the underlying infrastructure to provide their customers with fast loading times, unparalleled redundancy, and the strongest security — all through our Cloudflare for SaaS product. Today, we’re excited to give our SaaS providers new tools that will help them enhance the security of their customers’ applications.

For our Enterprise customers, we’re bringing WAF for SaaS — the ability for SaaS providers to easily create and deploy different sets of WAF rules for their customers. This gives SaaS providers the ability to segment customers into different groups based on their security requirements.

For developers who are getting their application off the ground, we’re thrilled to announce a Free tier of Cloudflare for SaaS for the Free, Pro, and Biz plans, giving our customers 100 custom hostnames free of charge to provision and test across their account. In addition to that, we want to make it easier for developers to scale their applications, so we’re happy to announce that we are lowering our custom hostname price from \$2 to \$0.10 a month.

But that’s not all! At Cloudflare, we believe security should be available for all. That’s why we’re extending a new selection of WAF rules to Free customers — giving all customers the ability to secure both their applications and their customers’.

At Cloudflare, we take pride in our Free tier which gives any customer the ability to make use of our Network to stay secure and online. We are eager to extend the same support to customers looking to build a new SaaS offering, giving them a Free tier of Cloudflare for SaaS and allowing them to onboard 100 custom hostnames at no charge. The 100 custom hostnames will be automatically allocated to new and existing Cloudflare for SaaS customers. Beyond that, we are also dropping the custom hostname price from \$2 to \$0.10 a month, giving SaaS providers the power to onboard and scale their application. Existing Cloudflare for SaaS customers will see the updated custom hostname pricing reflected in their next billing cycle.

Cloudflare for SaaS started as a TLS certificate issuance product for SaaS providers. Now, we’re helping our customers go a step further in keeping their customers safe and secure.

SaaS providers may have varying customer bases — from mom-and-pop shops to well established banks. No matter the customer, it's important that as a SaaS provider you’re able to extend the best protection for your customers, regardless of their size.

At Cloudflare, we have spent years building out the best Web Application Firewall for our customers. From managed rules that offer advanced zero-day vulnerability protections to OWASP rules that block popular attack techniques, we have given our customers the best tools to keep themselves protected. Now, we want to hand off the tools to our SaaS providers who are responsible for keeping their customer base safe and secure.

One of the benefits of Cloudflare for SaaS is that SaaS providers can configure security rules and settings on their SaaS zone which their customers automatically inherit. But one size does not fit all, which is why we are excited to give Enterprise customers the power to create various sets of WAF rules that they can then extend as different security packages to their customers — giving end users differing levels of protection depending on their needs.

WAF for SaaS can be easily set up. We have an example below that shows how you can configure different buckets of WAF rules to your various customers.

There’s no limit to the number of rulesets that you can create, so feel free to create a handful of configurations for your customers, or deploy one ruleset per customer — whatever works for you!

Cloudflare for SaaS customers define their customer’s domains by creating custom hostnames. Custom hostnames indicate which domains need to be routed to the SaaS provider’s origin. Custom hostnames can define specific domains, like example.com, or they can extend to wildcards like *.example.com which allows subdomains under example.com to get routed to the SaaS service. WAF for SaaS supports both types of custom hostnames, so that SaaS providers have flexibility in choosing the scope of their protection.

The first step is to create a custom hostname to define your customer’s domain. This can be done through the dashboard or the API.

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone:id}/custom_hostnames" \
     -H "X-Auth-Email: {email}" -H "X-Auth-Key: {key}"\
     -H "Content-Type: application/json" \
     --data '{

"Hostname":{“example.com”},
"Ssl":{wildcard: true}
}'

Next, create an association between the custom hostnames — your customer’s domain — and the firewall ruleset that you’d like to attach to it.

This is done by associating a JSON blob to a custom hostname. Our product, Custom Metadata allows customers to easily do this via API.

In the example below, a JSON blob with two fields (“customer_id” and “security_level”) will be associated to each request for *.example.com and example.com.

There is no predetermined schema for custom metadata. Field names and structure are fully customisable based on our customer’s needs. In this example, we have chosen the tag “security_level” to which we expect to assign three values (low, medium or high). These will, in turn, trigger three different sets of rules.

curl -sXPATCH "https://api.cloudflare.com/client/v4/zones/{zone:id}/custom_hostnames/{custom_hostname:id}"\
    -H "X-Auth-Email: {email}" -H "X-Auth-Key: {key}"\
    -H "Content-Type: application/json"\
    -d '{
"Custom_metadata":{
"customer_id":"12345",
“security_level”: “low”
}
}'

Finally, you can trigger a rule based on the custom hostname. The custom metadata field e.g. “security_level” is available in the Ruleset Engine where the WAF runs. In this example, “security_level” can be used to trigger different configurations of products such as WAF, Firewall Rules, Advanced Rate Limiting and Transform Rules.

Rules can be built through the dashboard or via the API, as shown below. Here, a rate limiting rule is triggered on traffic with “security_level” set to low.

curl -X PUT "https://api.cloudflare.com/client/v4/zones/{zone:id}/rulesets/phases/http_ratelimit/entrypoint" \
    -H "X-Auth-Email: {email}" -H "X-Auth-Key: {key}"\
    -H "Content-Type: application/json"\
    -d '{

"rules": [
              {
                "action": "block",
                "ratelimit": {
                  "characteristics": [
                    "cf.colo.id",
                    "ip.src"
                  ],
                  "period": 10,
                  "requests_per_period": 2,
                  "mitigation_timeout": 60
                },
                "expression": "lookup_json_string(cf.hostname.metadata, \"security_level\") eq \"low\" and http.request.uri contains \"login\""
              }
            ]
          }}'

If you’d like to learn more about our Advanced Rate Limiting rules, check out our documentation.

We’re excited to be the provider for our SaaS customers’ infrastructure needs. From custom domains to TLS certificates to Web Application Firewall, we’re here to help. Sign up for Cloudflare for SaaS today, or if you’re an Enterprise customer, reach out to your account team to get started with WAF for SaaS.

We are excited to share that Vectrix has been acquired by Cloudflare!

Vectrix helps IT and security teams detect security issues across their SaaS applications. We look at both data and users in SaaS apps to alert teams to issues ranging from unauthorized user access and file exposure to misconfigurations and shadow IT.

We built Vectrix to solve a problem that terrified us as security engineers ourselves: how do we know if the SaaS apps we use have the right controls in place? Is our company data protected? SaaS tools make it easy to work with data and collaborate across organizations of any size, but that also makes them vulnerable.

The past two years have accelerated SaaS adoption much faster than any of us could have imagined and without much input on how to secure this new business stack.

Google Workspace for collaboration. Microsoft Teams for communication. Workday for HR. Salesforce for customer relationship management. The list goes on.

With this new reliance on SaaS, IT and security teams are faced with a new set of problems like files and folders being made public on the Internet, external users joining private chat channels, or an employee downloading all customer data from customer relationship tools.

The challenge of securing users and data across even a handful of applications, each with its own set of security risks and a unique way of protecting it, is overwhelming for most IT and security teams. Where should they begin?

Enter the API-driven Cloud Access Security Broker (CASB). We think about an API-driven CASB as a solution that can scan, detect, and continuously monitor for security issues across organization-approved, IT-managed SaaS apps like Microsoft 365, ServiceNow, Zoom, or Okta.

CASB solutions help teams with:

• Data security - ensuring the wrong file or folder is not shared publicly in Dropbox.

• User activity - alerting to suspicious user permissions changing in Workday at 2:00 AM.

• Misconfigurations - keeping Zoom Recordings from becoming publicly accessible.

• Compliance - tracking and reporting who modified Bitbucket branch permissions.

• Shadow IT - detecting users that signed up for an unapproved app with their work email.

Securing SaaS applications starts with visibility into what users and data reside in a service, and then understanding how they’re used. From there, protective and preventive measures, within the SaaS application and on the network, can be used to ensure data stays safe.

It’s not always the extremely complex things either. A really good example of this came from an early Vectrix customer who asked if we could detect public Google Calendars for them. They recently had an issue where someone on the team had shared their calendar which contained several sensitive meeting links and passcodes. They would have saved themselves a headache if they could have detected this prior, and even better, been able to correct it in a few clicks.

In this SaaS age something as innocent as a calendar invite can introduce risks that IT and security teams now have to think about. This is why we’re excited to grow further at Cloudflare, helping more teams stay one step ahead.

A core component of an API-first approach is the access system, which powers integrations via an OAuth 2.0 or vendor marketplace app to authorize secure API access into SaaS services. This means the API-driven CASB works out of band, or not in the direct network path, and won’t cause any network slowdowns or require any network configuration changes.

In just a few clicks, you can securely integrate with SaaS apps from anywhere—no agents, no installs, no downloads.

Over a cup of coffee an IT or security system administrator can connect their company's critical SaaS apps and start getting visibility into data and user activity right away. In fact, we usually see no more than 15 minutes pass from creating an account to the first findings being reported.

By integrating with more and more organization-approved SaaS application patterns that may otherwise not be visible start to emerge.

For example, being alerted that Sam attempted to disable two-factor authentication in multiple SaaS applications may indicate a need for more security awareness training. Or being able to detect numerous users granting sensitive account permissions to an unapproved third-party app could indicate a possible phishing attempt.

The more integrations you protect the better your overall SaaS security becomes.

The entire Vectrix team has joined Cloudflare and will be integrating API-driven CASB functionality into the Cloudflare Zero Trust platform, launching later this year.

This means an already impressive set of growing products like Access (ZTNA), Gateway (SWG), and Browser Isolation, will be getting even better, together. Even more exciting though, is that using all of these services will be a seamless experience, managed from a unified Zero Trust platform and dashboard.

A few examples of what we’re looking forward to growing together are:

• Shadow IT: use Gateway to detect all your SaaS apps in use, block those that are unapproved, and use CASB to ensure your data stays safe in sanctioned ones.

• Secure access: use Access to ensure only users who match your device policies will be allowed into SaaS apps and CASB to ensure the SaaS app stays configured only for your approved authentication method.

• Data control: use Browser Isolation’s input controls to prevent users from copy/pasting or printing data and CASB to ensure the data isn’t modified to be shared publicly from within the SaaS app itself for total control.

Vectrix will be integrated into the Cloudflare Zero Trust platform to extend the security of Cloudflare’s global network to the data stored in SaaS applications from a single control plane.

If you’d like early beta access, please click here to join the waitlist. We will send invites out in the sign-up order we received them. You can learn more about the acquisition here.

This past April, we announced the Cloudflare for SaaS Beta which makes our SSL for SaaS product available to everyone. This allows any customer — from first-time developers to large enterprises — to use Cloudflare for SaaS to extend our full product suite to their own customers. SSL for SaaS is the subset of Cloudflare for SaaS features that focus on a customer’s Public Key Infrastructure (PKI) needs.

Today, we’re excited to announce all the customizations that our team has been working on for our Enterprise customers — for both Cloudflare for SaaS and SSL for SaaS.

If you’re running a SaaS company, your solution might exist as a subdomain of your SaaS website, e.g. template.<mysaas>.com, but ideally, your solution would allow the customer to use their own vanity hostname for it, such as example.com.

The most common way to begin using a SaaS company’s service is to point a CNAME DNS record to the subdomain that the SaaS provider has created for your application. This ensures traffic gets to the right place, and it allows the SaaS provider to make infrastructure changes without involving your end customers.

We kept this in mind when we built our SSL for SaaS a few years ago. SSL for SaaS takes away the burden of certificate issuance and management from the SaaS provider by proxying traffic through Cloudflare’s edge. All the SaaS provider needs to do is onboard their zone to Cloudflare and ask their end customers to create a CNAME to the SaaS zone — something they were already doing.

The big benefit of giving your customers a CNAME record (instead of a fixed IP address) is that it gives you, the SaaS provider, more flexibility and control. It allows you to seamlessly change the IP address of your server in the background. For example, if your IP gets blocked by ISP providers, you can update that address on your customers’ behalf with a CNAME record. With a fixed A record, you rely on each of your customers to make a change.

While the CNAME record works great for most customers, some came back and wanted to bypass the limitation that CNAME records present. RFC 1912 states that CNAME records cannot coexist with other DNS records, so in most cases, you cannot have a CNAME at the root of your domain, e.g. example.com. Instead, the CNAME needs to exist at the subdomain level, i.e. www.example.com. Some DNS providers (including Cloudflare) bypass this restriction through a method called CNAME flattening.

Since SaaS providers have no control over the DNS provider that their customers are using, the feedback they got from their customers was that they wanted to use the apex of their zone and not the subdomain. So when our SaaS customers came back asking us for a solution, we delivered. We call it Apex Proxying.

For our SaaS customers who want to allow their customers to proxy their apex to their zone, regardless of which DNS provider they are using, we give them the option of Apex Proxying. Apex Proxying is an SSL for SaaS feature that gives SaaS providers a pair of IP addresses to provide to their customers when CNAME records do not work for them.

Cloudflare starts by allocating a dedicated set of IPs for the SaaS provider. The SaaS provider then gives their customers these IPs that they can add as A or AAAA DNS records, allowing them to proxy traffic directly from the apex of their zone.

While this works for most, some of our customers want more flexibility. They want to have multiple IPs that they can change, or they want to assign different sets of customers to different buckets of IPs. For those customers, we give them the option to bring their own IP range, so they control the IP allocation for their application.

Last year, we announced Bring Your Own IP (BYOIP), which allows customers to bring their own IP range for Cloudflare to announce at our edge. One of the benefits of BYOIP is that it allows SaaS customers to allocate that range to their account and then, instead of having a few IPs that their customers can point to, they can distribute all the IPs in their range.

SaaS customers often require granular control of how their IPs are allocated to different zones that belong to different customers. With 256 IPs to use, you have the flexibility to either group customers together or to give them dedicated IPs. It’s up to you!

While we’re on the topic of grouping customers, let’s talk about how you might want to do this when sending traffic to your origin.

When setting up Cloudflare for SaaS, you indicate your fallback origin, which defines the origin that all of your Custom Hostnames are routed to. This origin can be defined by an IP address or point to a load balancer defined in the zone. However, you might not want to route all customers to the same origin. Instead, you want to route different customers (or custom hostnames) to different origins — either because you want to group customers together or to help you scale the origins supporting your application.

Our Enterprise customers can now choose a custom origin that is not the default fallback origin for any of their Custom Hostnames. Traditionally, this has been done by emailing your account manager and requesting custom logic at Cloudflare's edge, a very cumbersome and outdated practice. But now, customers can easily indicate this in the UI or in their API requests.

Oftentimes, SaaS providers have customers that don’t just want their domain to stay protected and encrypted, but also the subdomains that fall under it.

We wanted to give our Enterprise customers the flexibility to extend this benefit to their end customers by offering wildcard support for Custom Hostnames.

Wildcard Custom Hostnames extend the Custom Hostname’s configuration from a specific hostname — e.g. “blog.example.com” — to the next level of subdomains of that hostname, e.g. “*.blog.example.com”.

To create a Custom Hostname with a wildcard, you can either indicate Enable wildcard support when creating a Custom Hostname in the Cloudflare dashboard or when you’re creating a Custom Hostname through the API, indicate wildcard: “true”.

Now let’s switch gears to TLS certificate management and the improvements our team has been working on.

SSL for SaaS was built to reduce the burden of certificate management for SaaS providers. The initial functionality was meant to serve most customers and their need to issue, maintain, and renew certificates on their customers’ behalf. But one size does not fit all, and some of our customers have more specific needs for their certificate management — and we want to make sure we accommodate them.

One of the superpowers of SSL for SaaS is that it allows Cloudflare to manage all the certificate issuance and renewals on behalf of our customers and their customers. However, some customers want to allow their end customers to upload their own certificates.

For example, a bank may only trust certain certificate authorities (CAs) for their certificate issuance. Alternatively, the SaaS provider may have initially built out TLS support for their customers and now their customers expect that functionality to be available. Regardless of the reasoning, we have given our customers a few options that satisfy these requirements.

For customers who want to maintain control over their TLS private keys or give their customers the flexibility to use their certification authority (CA) of choice, we allow the SaaS provider to upload their customer’s certificate.

If you are a SaaS provider and one of your customers does not allow third parties to generate keys on their behalf, then you want to allow that customer to upload their own certificate. Cloudflare allows SaaS providers to upload their customers’ certificates to any of their custom hostnames — in just one API call!

Some SaaS providers never want a person to see private key material, but want to be able to use the CA of their choice. They can do so by generating a Certificate Signing Request (CSR) for their Custom Hostnames, and then either use those CSRs themselves to order certificates for their customers or relay the CSRs to their customers so that they can provision their own certificates. In either case, the SaaS provider is able to then upload the certificate for the Custom Hostname after the certificate has been issued from their customer’s CA for use at Cloudflare’s edge.

For our customers who need to customize their configuration to handle specific rules for their customer’s domains, they can do so by using Custom Metadata and Workers.

By adding metadata to an individual custom hostname and then deploying a Worker to read the data, you can use the Worker to customize per-hostname behavior.

Some customers use this functionality to add a customer_id field to each custom hostname that they then send in a request header to their origin. Another way to use this is to set headers like HTTP Strict Transport Security (HSTS) on a per-customer basis.

Tomorrow, we have a very special announcement about how you can now get more visibility into your customers’ traffic and — more importantly —  how you can share this information back to them.

If you’re an Enterprise customer, and you’re interested in any of these features, reach out to your account team to get access today!

Most teams start that journey by moving the applications that lived on their private networks into this Zero Trust model. Instead of a private network where any user on the network is assumed to be trusted, the applications that use Cloudflare Access now check every attempt against the rules you create. For your end users, this makes these applications just feel like regular SaaS apps, while your security teams have full control and logs.

However, we kept hearing from teams that wanted to use their Access control plane to apply consistent security controls to their SaaS apps, and consolidate logs from self-hosted and SaaS in one place.

We’re excited to give your team the tools to solve that challenge. With Access in front of your SaaS applications, you can build Zero Trust rules that determine who can reach your SaaS applications in the same place where your rules for self-hosted applications and network access live. To make that easier, we are launching guided integrations with the Amazon Web Services (AWS) management console, Zendesk, and Salesforce. In just a few minutes, your team can apply a Zero Trust layer over every resource you use and ensure your logs never miss a request.

Cloudflare Access secures applications that you host by becoming the authoritative DNS for the application itself. All DNS queries, and subsequent HTTP requests, hit Cloudflare’s network first. Once there, Cloudflare can apply the types of identity-aware and context-driven rules that make it possible to move to a Zero Trust model. Enforcing these rules in our network means your application doesn’t need to change. You can secure it on Cloudflare, integrate your single sign-on (SSO) provider and other systems like Crowdstrike and Tanium, and begin building rules.

SaaS applications pose a different type of challenge. You do not control where your SaaS applications are hosted — and that’s a big part of the value. You don’t need to worry about maintaining the hardware or software of the application.

However, that also means that your team cannot control how users reach those resources. In most cases, any user on the Internet can attempt to log in. Even if you incorporate SSO authentication or IP-based allowlisting, you might not have the ability to add location or device rules. You also have no way to centrally capture logs of user behavior on a per-request basis. Logging and permissions vary across SaaS applications — some are quite granular while others have non-existent controls and logging.

Cloudflare Access for SaaS solves that problem by injecting Zero Trust checks into the SSO flow for any application that supports SAML authentication. When users visit your SaaS application and attempt to log in, they are redirected through Cloudflare and then to your identity provider. They authenticate with your identity provider and are sent back to Cloudflare, where we layer on additional rules like device posture, multi factor method, and country of login. If the user meets all the requirements, Cloudflare converts the user’s authentication with your identity provider into a SAML assertion that we send to the SaaS application.

We built support for SaaS applications by using Workers to take the JWT and convert its content into SAML assertions that are sent to the SaaS application. The application thinks that Cloudflare Access is the identity provider, even though we’re just aggregating identity signals from your SSO provider and other sources into the JWT, and sending that summary to the app via SAML. All of this leverages Cloudflare’s global network and ensures users do not see a performance penalty.

COVID-19 made it commonplace for employees to work from anywhere and, more concerning, from any device. Many SaaS applications contain sensitive data that should only be accessed with a corporately managed device. A benefit of SaaS tools is that they’re readily available from any device, it’s up to security administrators to enforce which devices can be used to log in.

Once Access for SaaS has been configured as the SSO provider for SaaS applications, policies that verify a device can be configured. You can then lock a tool like Salesforce down to only users with a device that has a known serial number, hard auth key plugged in, an up to date operating system and much more.

Cloudflare Gateway keeps your users and data safe from threats on the Internet by filtering Internet-bound connections that leave laptops and offices. Gateway gives administrators the ability to block, allow, or log every connection and request to SaaS applications.

However, users are connecting from personal devices and home WiFi networks, potentially bypassing Internet security filtering available on corporate networks. If users have their password and MFA token, they can bypass security requirements and reach into SaaS applications from their own, unprotected devices at home.

To ensure traffic to your SaaS apps only connects over Gateway-protected devices, Cloudflare Access will add a new rule type that requires Gateway when users login to your SaaS applications. Once enabled, users will only be able to connect to your SaaS applications when they use Cloudflare Gateway. Gateway will log those connections and provide visibility into every action within SaaS apps and the Internet.

It’s easy to get started with setting up Access for SaaS application. Visit the Cloudflare for Teams Dashboard and follow one of our published guides.

We will make it easier to protect SaaS applications and will soon be supporting configuration via metadata files. We will also continue to publish SaaS app specific integration guides. Are there specific applications you’ve been trying to integrate? Let us know in the community!

Software as a Service (SaaS) is one of the fastest-growing business segments in the IT market. SaaS providers can be anything from a web hosting provider to a subscription service, to an e-commerce platform. While well-known SaaS providers are industry giants, every day new SaaS companies are created, with the potential to become the next Salesforce.

But while it’s a fast-growing segment, if you’re a SaaS company, you know it’s not an easy path to forge.

Cloudflare released a solution to help our SaaS customers four years ago — it’s called SSL for SaaS. It’s perfect for those who need to manage their customers’ websites and SSL certificates at scale, and it’s been adopted by some of the leading SaaS companies in the world, from WP Engine to Shopify to HubSpot. As the product has evolved, it has become a one-stop-shop for SaaS providers looking to provide fast load times, unparalleled redundancy, and the strongest security to their customers. Now, over 10 million applications have inherited the full benefits of the Cloudflare network through their SaaS provider.

Before today, SSL for SaaS was only available to Enterprise customers. Today, we are excited to announce that our SaaS solution is available to everyone. And to reflect the evolution of the product since it was first released, we’re changing the name: Cloudflare for SaaS.

The beta is available today — submit your request here to try it out!

If you're starting a SaaS business, the value proposition is clear: Cloudflare for SaaS takes care of your underlying infrastructure, enabling you to keep your team lean and focused on building out your core solution. We’ve spent years investing in certificate issuance, building out our security and performance suite of products. Now we make it easy for you to extend all of the benefits we provide for your domain, to your end customers.

We know first hand the many challenges of building a successful SaaS business. We are not going to tell you how to run your business, but we can share what we've learned about the core infrastructure requirements — and how Cloudflare is well-positioned to address them.

Today, the way many SaaS providers offer their services is by giving their customers a web application that’s hosted on their origin (or, often, on Cloudflare).

Suppose you’re building a SaaS service for building e-commerce sites. You can give your customers a dedicated subdomain, like myshop.example.com, but it’s likely that your customers will come back asking to run the application on myshopsactualname.com. To give customers a branded experience, SaaS providers are required to support vanity domains.

This is more onerous than it sounds.

Once an application has been spun up, the next step is to provision TLS certificates for both the SaaS provider’s application and their customers. Developers may start looking into building out their homespun solution where they have to architect a whole pipeline around making API calls to a Certificate Authority. That means validating certificates, renewing them, and storing them.  There are many states to account for in order to prevent certificate failures and uptime for your customers, which translates into a heavy engineering investment.

But here’s the thing: every hour of time you invest in doing this, is an hour that can’t be spent on engineering efforts to build out the core part of your business.

You don’t have to just take our word for it. In building SSL for SaaS, we got to learn from best-in-class engineering teams who were running into challenges managing complex certificate management systems. HubSpot, for example, rolled out their in-house solution in 2015 where they deployed SSL certificates that were shared amongst their customers. This became a short-term solution when they began to run into scaling difficulties, resulting in slow certificate deployment, and leaving their customers with an unsatisfactory experience.

Cloudflare has been focused on certificate provisioning and management for many years — it’s at the core of our business. When we launched Universal SSL in 2014, we built our SSL pipeline to manage millions of certificates. We then decided to extend the benefits of our managed certificate issuance platform in 2017 to our SaaS provider customers, allowing them to secure their customer’s websites that they are responsible for managing.

This allowed customers like Hubspot to secure thousands of domains, without dedicating a big amount of engineering effort towards it. But while SSL for SaaS was originally built to handle certificate issuance, management, and renewals on behalf of our customers and their own customers, we’ve extended our solution far beyond just that.

For SaaS providers, their customers’ businesses are reliant on them staying online, always being available, and being performant. When their customers sign up for their business, that’s the underlying promise that the SaaS provider is making.

Every day, the Internet sees attacks, malicious traffic, unexpected spikes in requests, and so on.

At Cloudflare, we’ve heavily invested in building out one of the largest, most resilient networks, with solutions that keep your applications and origins protected. This is one of our core value propositions for customers, and now SaaS-providers can extend it to their customers, too. With built-in DDoS mitigation, a resilient Web Application Firewall (WAF), and a Carrier-grade Bot Management solution, you can prevent costly disruptions and downtime for you and your customers, so that regardless of who attackers are targeting, you both stay online.

We not only take the burden off your engineering and support teams, but we make it easy for your end customers to inherit your security settings. Whatever benefits you set up for yourself, your customers will instantly assume them.

As a business, you want to provide the best experience for your users. Speed plays a big part in how we perceive our online experiences.

For SaaS businesses, investing in performance is a must. When doing so, you need to keep in mind that your customers are global and their eyes are located worldwide, meaning that end users might not always be close to your origin server.

Cloudflare for SaaS allows you to take advantage of our performant Anycast network with data centers in more than 100 countries that, when coupled with our speed and performance features like caching and Argo Smart Routing, can improve performance by 30%. This means that, if you’re an e-commerce site and your origin server is in North America, your global customers in Asia will get the same lightning-fast load times that your US visitors get, giving every customer the best experience.

In January, we announced on Twitter that we had an SSL for SaaS beta open. What we didn’t expect was that ~80% of our beta users were building their SaaS application on Workers. In retrospect, it makes total sense: in the same way that managing and scaling an SSL pipeline can take precious time and resources from building out the core business, managing and scaling infrastructure can be costly and time-consuming.

By marrying Cloudflare for SaaS with Workers, SaaS companies can unleash their developers — we’ll take care of not just certificate management, security, and performance, but also the burden of infrastructure.

You write the code, and we’ll take care of the rest.

The best part of building for developers is getting to see what they build. Here, we’re going to showcase some of the amazing projects already built on our platform that have taken the path we’ve just described:

Statusflare is a tool for monitoring your websites and applications because the only thing worse than downtime is not knowing about it. The Statusflare team has built out a solution that allows businesses to deploy global checks around the world to monitor uptime, metrics, and server response time. Beyond that, they allow their customers to deploy status pages, so their customers stay informed about the availability of their services.

When building out their status page product, the Statusflare team decided to use Workers as their deployment platform. This allowed them to spend all their time writing code and building out their API, and zero time worrying about deploying an origin server. Once the Statusflare team had finished building their application, they were ready to integrate it with their customers’ vanity domains, so that anyone could set up a status page for their website.

The challenge they then faced was getting their customers the latest version of their product. To start, they decided to open source their solution, give their customers the Workers script, and have their customers deploy it to get their status page up and running. But this makes updates complicated, and instead of giving their end-users the latest version, customers were now responsible for updates.

Not just that — they also had to spend time integrating with certificate authorities to issue certificates, so their customers’ pages stay protected.

Statusflare found that Cloudflare for SaaS was the perfect solution to help them grow. With easy-to-use integration for custom domains, all they now had to do was to click a few buttons, and their end-users could use a vanity domain, pull the latest update of the status page, and get a certificate deployed. Beyond that, Statusflare is now looking to integrate their solution with Cloudflare Access and Teams, so their customers can keep their monitoring private and only allow authorized users. With built-in security and rate limiting, Statusflare never has to worry about the number of incoming requests, or scaling their application. Statusflare was very excited to share that having everything in one place means that they don’t have to worry about scaling or provisioning servers, they don’t have to worry about the availability of their customer’s domains, and instead of investing time in keeping their application stable, they can now focus on writing code and building out their product.

With Cloudflare, our application scales on its own, it scales to infinity.- Adam, founder of Statusflare.

PLUMA is an audio hosting service, a blogging platform, and a privacy-focused analytics service for websites and mobile apps that is currently in the making. It’s built on Workers, meaning the application fully runs on Cloudflare’s edge, with 0ms cold starts. With Workers KV, PLUMA is able to store all of its data, i.e. session data, static files, and logs, on Cloudflare’s edge, providing their end-users with a low latency service. One of the biggest requests from PLUMA users was for customers to be able to use their own branded domain, instead of one that PLUMA provides. With Cloudflare for SaaS, PLUMA can easily offer this experience to their end-users, with the extended benefit of keeping their customers’ sites secured with a TLS certificate.

Cloudflare for SaaS makes it easy to integrate any number of domains with Workers. This makes Cloudflare a wonderful platform for building out low latency serverless applications.- Pier Bover, founder of PLUMA

Plink makes universal links for podcasts. One of the top feature requests from their customers has been to have their own custom domains. As an early-stage startup, Plink was looking for a cost-effective solution that would help them optimize their application, scale, and provide a customized experience for their users. With Workers and Workers KV, they were able to optimize their core scripts and functionality, without worrying about DevOps. This, coupled with Cloudflare for SaaS, allowed them to create a “custom-branded” experience of their service to external domains that were owned by their customers.

Connecting Plink’s API with Cloudflare’s API has been a seamless experience. In general, building with Workers is amazing! I'm excited to provide a branded experience for Plink customers with Cloudflare for SaaS. - Scott Mathson, Founder at Plink

When developers are starting to build out their next SaaS application, there’s a long list of things they don’t want to worry about. Instead of allocating their engineering resources to work on their infrastructure, they should be dedicating their time building the next billion dollar business.

That’s what we’re enabling. And with our beta announced today, we’re doing it for everyone.

The end result: you can build the next groundbreaking SaaS business, and we’ll take care of the rest. To sign up for the beta, submit your request here. We will be admitting customers on a rolling basis, and allotting 20 custom hostnames to each domain.

Request to join our beta here!

While we’re super excited about making Cloudflare for SaaS available to everyone, we know that our largest Enterprise customers have some demanding and specialized needs. We’ve been hard at work to build out new features to satisfy them. Stay tuned for an exciting announcement in the upcoming weeks!

As the  number of SaaS services people use everyday grows, it has become more challenging to juggle the number of password and multi-factor authentication combinations users have to keep track of to get online.

Adopting identity services have allowed companies to centralize employee authentication. With Cloudflare Access, companies can ensure employees use a company managed identity provider when accessing websites behind Cloudflare. Last week, Sam published a blog on how Cloudflare has made it easier to connect Cloudflare Access to the Atlassian suite of tools.

Since Cloudflare has simplified access control for corporate applications, many enterprise customers have commonly asked for the ability to extend the same ease of access and control to the Cloudflare dashboard itself.

Today, we are announcing support for enterprise customers to use single sign-on (SSO) through their identity provider to access the Cloudflare dashboard.

Cloudflare is a critical piece of infrastructure for customers, and SSO ensures that customers can apply the same authentication policies to access the Cloudflare dashboard as other critical resources.

Once onboarded for SSO, all company user logins to the Cloudflare dashboard redirect to the customer’s identity provider. Once all required authentication checks complete successfully, the user is seamlessly redirected back to dash.cloudflare.com and logged in.

At Cloudflare, we  dogfood our own services as both a way to make them better for our customers and to make developing new services more efficient and robust. With SSO, this is no different. Authentication configurations are managed through Access, which allows us to launch with support for the same identity providers available in Access today, including SAML.

Cloudflare is 8 years old and we built our user authentication system way before Cloudflare Access existed. In order to connect Access to our existing authentication system, we built a Cloudflare Worker that converts Access authentication tokens to our own authentication tokens. This greatly simplified the code changes required in our system, and results in faster SSO logins because the Worker runs at the network edge and reduces the number of round trips required to authenticate users.

In addition to leveraging Cloudflare services to build Single Sign-On, we are moving all Cloudflare employees to use SSO through our existing G Suite setup. This ensures Cloudflare can uniformly enforce multi-factor authentication policies for the services we protect with Cloudflare itself.

Cloudflare Enterprise customers can reach out to their Customer Success Manager to learn how to start using SSO to log-in to the Cloudflare dashboard. If you are interested in using SSO yourself and becoming a Cloudflare Enterprise customer, then please get in touch.

In the run-up to Thanksgiving and Black Friday, e-commerce sites turned to services like Cloudflare to help optimise their performance and withstand the traffic spikes of the shopping season.

In preparation, an e-commerce customer joined Cloudflare on the 9th November, a few weeks before the shopping season. Instead of joining via our Enterprise plan, they were a self-serve customer who signed-up by subscribing to our Business plan online and switching their nameservers over to us.

Their site was running Magento, a notably slow e-commerce platform - filled with lots of interesting PHP, with a considerable amount of soft code in XML. Running version 1.9, the platform was somewhat outdated (Magento was totally rewritten in version 2.0 and subsequent releases).

Despite the somewhat dated technology, the e-commerce site was "good enough" for this customer and had done it's job for many years.

They were the first to notice an interesting technical issue surrounding how performance and security can often feel at odds with each other. Although they were the first to highlight this issue, into the run-up of Black Friday, we ultimately saw around a dozen customers on Magento 1.8/1.9 have similar issues.

After signing-up for Cloudflare, the site owners attempted to make some changes to ensure their site was loading quickly.

The website developers had already ensured the site was loading over HTTPS, in doing so they were able to ensure their site was loading over the new HTTP/2 Protocol and made some changes to ensure their site was optimised for HTTP/2 (for details, see our blog post on HTTP/2 For Web Developers).

At Cloudflare we've taken steps to ensure that there isn't a latency overhead for establishing a secure TLS connection, here is a non-complete list of optimisations we use:

• TLS Session Resumption

• OCSP Stapling

• Fast Elliptic Curve Cryptography prioritised

• Dynamic TLS Record Sizing

Additionally, they had enabled HTTP/2 Server Push to ensure critical CSS/JS assets could be pushed to clients when they made their first request. Without Server Push, a client has to download the HTML response, interpret it and then work out assets it needs to download.

Big images were Lazy Loaded, only downloading them when they needed to be seen by the users. Additionally, they had enabled a Cloudflare feature called Polish. With this enabled, Cloudflare dynamically works out whether it's faster serve an image in WebP (a new image format developed by Google) or whether it's faster to serve it in a different format.

These optimisations did make some improvement to performance, but their site was still slow.

In web performance, there are a few different things which can affect the response times - I've crudely summarised them into the following three categories:

• Connection & Request Time - Before a request can be sent off for a website to load something, a few things need to happen: DNS queries, a TCP handshake to establish the connection with the web server and a TLS handshake to establish a secure connection

• Page Render - A dynamic site needs to query databases, call APIs, write logs, render views, etc before a response can be made to a client

• Response Speed - Downloading the response from web server, browser-side rendering of the HTML and pulling the other resources linked in the HTML

The e-commerce site had taken steps to improve their Response Speed by enabling HTTP/2 and performing other on-site optimisations. They had also optimised their Connection & Response Time by using a CDN service like Cloudflare to provide fast DNS and reduce latency when optimising TLS/TCP connections.

However, they now realised the critical step they needed to optimise was around the Page Render that would happen on their web server.

By looking at a Waterfall View of how their site loaded (similar to the one below) they could see the main constraint.

Example Waterfall view from WebSiteOptimization.com

On the initial request, you can see the green "Time to First Byte" view taking a very long time.

Many browsers have tools for viewing Waterfall Charts like the one above, Google provide some excellent documentation for Chrome on doing this: Get Started with Analyzing Network Performance in Chrome DevTools. You can also generate these graphs fairly easily from site speed test tools like WebPageTest.org.

Time to First Byte itself is an often misunderstood metric and often can't be attributed to a single fault. For example; using a CDN service like Cloudflare may increase TTFB by a few milliseconds, but do so to the benefit of an overall load time. This can be as the CDN is adding additional compression functionality to speed up the response, or simply as it has to establish a connection back to the origin web server (which isn't visible by the client).

There are instances where it is important to debug why TTFB is a problem. For example; in this instance, the e-commerce platform was taking upwards of 3 seconds just to generate the HTML response. In this case, it was clear the constraint was the server-side Page Render.

When the web server was generating dynamic content, it was having to query databases and perform logic before a request could be served. In most instances (i.e. a product page) the page would be identical to every other request. It would only be when someone would add something to their shopping cart that the site would really become dynamic.

Before someone logs into the the Magento admin panel or adds something to their shopping cart, the page view is anonymous and will be served up identically to every visitor. It will only be the when an anonymous visitor logs in or adds something to their shopping cart that they will see a page that's dynamic and unlike every other page that's been rendered.

It therefore is possible to cache those anonymous requests so that Magento on an origin server doesn't need to constantly regenerate the HTML.

Cloudflare users on our Business Plan are able to cache anonymous page views when using Magneto using our Bypass Cache on Cookie functionality. This allows for static HTML to be cached at our edge, with no need for it to be regenerated from request to request.

This provides a huge performance boost for the first few page visits of a visitor, and allows them still to interact with the dynamic site when they need to. Additionally, it helps keep load down on the origin server in the event of traffic spikes, sparing precious server CPU time for those who need it to complete dynamic actions like paying for an order.

Here's an example of how this can be configured in Cloudflare using the Page Rules functionality:

The Page Rule configuration above instructs Cloudflare to "Cache Everything (including HTML), but bypass the cache when it sees a request which contains any of the cookies: external_no_cache, PHPSESSID or adminhtml. The final Edge Cache TTL setting just instructs Cloudflare to keep HTML files in cache for a month, this is necessary as Magento by default uses headers to discourage caching.

The site administrator configured their site to work something like this:

1. On the first request, the user is anonymous and their request indistinguishable from any other - their page can be served from the Cloudflare cache

2. When the customer adds something to their shopping cart, they do that via a POST request - as methods like POST, PUT and DELETE are intended to change a resource, they bypass the Cloudflare cache

3. On the POST request to add something to their shopping cart, Magento will set a cookie called external_no_cache

4. As the site owner has configured Cloudflare to bypass the cache when we see a request containing the external_no_cache cookie, all subsequent requests go direct to origin

This behaviour can be summarised in the following crude diagram:

The site administrators initially enabled this configuration on a subdomain for testing purposes, but noticed something rather strange. When they would add something to the cart on their test site, the cart would show up empty. If they then tried again to add something to the cart, the item would be added successfully.

The customer reported one additional, interesting piece of information - when they tried to mimic this cookie-based caching behaviour internally using Varnish, they faced the exact same issue.

In essence, the Add to Cart functionality would fail, but only on the first request. This was indeed odd behaviour, and the customer reached out to Cloudflare Support.

The customer wrote in just as our Singapore office were finishing up their afternoon and was initially triaged by a Support Engineer in that office.

The Support Agent evaluated what the problem was and initially identified that if the frontend cookie was missing, the Add to Cart functionality would fail.

No matter which page you access on Magento, it will attempt to set a frontend cookie, even if it doesn't add an external_no_cache cookie

When Cloudflare caches static content, the default behaviour is to strip away any cookies coming from the server if the file is going to end up in cache - this is a security safeguard to prevent customers accidentally caching private session cookies. This applies when a cached response contains a Set-Cookie header, but does not apply when the cookie is set via JavaScript - in order to allow functionality like Google Analytics to work.

They had identified that the caching logic at our network edge was working fine, but for whatever reason Magento would refuse to add something to a shopping cart without a valid frontend cookie. Why was this?

As Singapore handed their shift work over to London, the Support Engineer working on this ticket decided to escalate the ticket up to me. This was largely as, towards the end of last year, I had owned the re-pricing of this feature (which opened it up to our self-service Business plan users, instead of being Enterprise-only). That said; I had not touched Magneto in many years, even when I was working in digital agencies I wasn't the most enthusiastic to build on it.

The Support Agent provided some internal comments that described the issue in detail and their own debugging steps, with an effective "TL;DR" summary:

Debugging these kinds of customer issues is not as simple as putting breakpoints into a codebase. Often, for our Support Engineers, the customers origin server acts as a black-box and there can be many moving parts, and they of course have to manage the expectations of a real customer at the other end. This level of problem solving fun, is one of the reasons I still like answering customer support tickets when I get a chance.

Before attempting to debug anything, I double checked that the Support Agent was correct that nothing had gone wrong on our end - I trusted their judgement and no others customers were reporting their caching functionality had broken, but it is always best to cross-check manual debugging work. I ran some checks to ensure that there were no regressions in our Lua codebase that controls caching logic:

• Checked that there were no changes to this logic in our internal code respository

• Check that automated tests are still in place and build successfully

• Run checks on production to verify that caching behaviour still works as normal

As Cloudflare has customers across so many platforms, I also checked to ensure that there were no breaking changes in Magento codebase that would cause this bug to occur. Occasionally we find our customers accidentally come across bugs in CMS platforms which are unreported. This, fortunately, was not one of those instances.

The next step is to attempt to replicate the issue locally and away from the customers site. I spun up a vanilla instance of Magento 1.9 and set it up with an identical Cloudflare configuration. The experiment was successful and I was able to replicate the customer issue.

I had an instinctive feeling that it was the Cross Site Request Forgery Protection functionality that was at fault here and I started tweaking my own test Magento installation to see if this was the cases.

Cross Site Request Forgery attacks work by exploiting the fact that one site on the internet can get a client to make requests to another site.

For example; suppose you have an online bank account with the ability to send money to other accounts. Once logged in, there is a form to send money which uses the following HTML:

<form action="https://example.com/send-money">
Account Name:
<input type="text" name="account_name" />
Amount:
<input type="text" name="amount" />
<input type="submit" />
</form>

After logging in and doing your transactions, you don't log-out of the website - but you simply navigate elsewhere online. Whilst browsing around you come across a button on a website that contains the text "Click me! Why not?". You click the button, and £10,000 goes from your bank account to mine.

This happens because the button you clicked was connected to an endpoint on the banking website, and contained hidden fields instructing it to send me £10,000 of your cash:

<form action="https://example.com/send-money">
<input type="hidden" name="account_name" value="Junade Ali" />
<input type="hidden" name="amount" value="10,000" />
<input type="submit" value="Click me! Why not?" />
</form>

In order to prevent these attacks, CSRF Tokens are inserted as hidden fields into web forms:

<form action="https://example.com/send-money">
Account Name:
<input type="text" name="account_name" />
Amount:
<input type="text" name="amount" />
<input type="hidden" name="csrf_protection" value="hunter2" />
<input type="submit" />
</form>

A cookie is first set on the clients computer containing a random session cookie. When a form is served to the client, a CSRF token is generated using that cookie. The server will check that the CSRF token submitted in the HTML form actually matches the session cookie, and if it doesn't block the request.

In this instance, as there was no session cookie ever set (Cloudflare would strip it out before it entered cache), the POST request to the Add to Cart functionality could never verify the CSRF token and the request would fail.

Due to CSRF vulnerabilities, Magento applied CSRF protection to all forms; this broke Full Page Cache implementations in Magento 1.8.x/1.9.x. You can find all the details in the SUPEE-6285 patch documentation from Magento.

To validate that CSRF Tokens were definitely at fault here, I completely disabled CSRF Protection in Magento. Obviously you should never do this in production, I found it slightly odd that they even had a UI toggle for this!

Another method which was created in the Magento Community was an extension to disable CSRF Protection just for the Add To Cart functionality (Inovarti_FixAddToCartMage18), under the argument that CSRF risks are far reduced when we're talking about Add to Cart functionality. This is still not ideal, we should ideally have CSRF Protection on every form when we're talking about actions which change site behaviour.

There is, however, a third way. I did some digging and identified a Magento plugin that effectively uses JavaScript to inject a dynamic CSRF token the moment a user clicks the Add to Cart button but just before the request is actually submitted. There's quite a lengthy Github thread which outlines this issue and references the Pull Requests which fixed this behaviour in the the Magento Turpentine plugin. I won't repeat the set-up instructions here, but they can be found in an article I've written on the Cloudflare Knowledge Base: Caching Static HTML with Magento (version 1 & 2)

Effectively what happens here is that the dynamic CSRF token is only injected into the web page the moment that it's needed. This is actually the behaviour that's implemented in other e-commerce platforms and Magento 2.0+, allowing Full Page Caching to be implemented quite easily. We had to recommend this plugin as it wouldn't be practical for the site owner to simply update to Magneto 2.

One thing to be wary of when exposing CSRF tokens via an AJAX endpoint is JSON Hijacking. There are some tips on how you can prevent this in the OWASP AJAX Security Cheat Sheet. Iain Collins has a Medium post with further discussion on the security merits of CSRF Tokens via AJAX (that said, however you're performing CSRF prevention, Same Origin Policies and HTTPOnly cookies FTW!).

There is an even cooler way you can do this using Cloudflare's Edge Workers offering. Soon this will allow you to run JavaScript at our Edge network, and you can use that to dynamically insert CSRF tokens into cached content (and, then either perform cryptographic validation of CSRF either at our Edge or the Origin itself using a shared secret).

Another interesting observation is that the Magento patch which caused this interesting behaviour had been around since July 7, 2015. Why did our Support Team only see this issue in the run-up to Black Friday in 2017? What's more, we ultimately saw around a dozen support tickets around this exact issue on Magento 1.8/1.9 over the course over 6 weeks.

When an Enterprise customer ordinarily joins Cloudflare, there is a named Solutions Engineer who gets them up and running and ensures there is no pain; however when you sign-up online with a credit card, your forgo this privilege.

Last year, we released Bypass Cache on Cookie to self-serve users when a lot of e-commerce customers were in their Christmas/New Year release freeze and not making changes to their websites. Since then, there were no major shopping events; most the sites enabling this feature were new build websites using Magento 2 where this wasn't an issue.

In the run-up to Black Friday, performance and coping under load became a key consideration for developers working on legacy e-commerce websites - and they turned to Cloudflare. Given the large, but steady, influx of e-commerce websites joining Cloudflare - the low overall percentage of those on Magento 1.8/1.9 became noticeable.

Caching anonymous page views is an important, and in some cases, essential mechanism to dramatically improve site performance to substantially reduce site load, especially during traffic spikes. Whilst aggressively caching content when users are anonymous, you can bypass the cache and allow users to use the dynamic functionality your site has to offer.

When you need to insert a dynamic state into cached content, JavaScript offers a nice compromise. JavaScript allows us to cache HTML for anonymous page visits, but insert a state when the users interact in a certain way. In essence, defusing this conflict between performance and security. In the future you'll be able to run this JavaScript logic at our network edge using Cloudflare Edge Workers.

It also remains important to respect the RESTful properties of HTTP and ensure GET, OPTIONS and HEAD requests remain safe and instead using POST, PUT, PATCH and DELETE as necessary.

If you're interested in debugging interesting technical problems on a network that sees around 10% of global internet traffic, we're hiring for Support Engineers in San Francisco, London, Austin and Singapore.

If your customers interact with your app on your domain and don’t care about branding under their custom or “vanity” domain (or aren’t paying you for the ability to do so), the solution is straightforward: onboard your domain to Cloudflare and serve the app at either https://app.yourcompany.ltd or https://yourcustomer.yourcompany.ltd. But if your customers want to host your application, portal, content management solution, etc. on their own domain for improved SEO and discoverability, e.g., https://app.yourcustomer.site the solution is not so easy.

Until today, your best bet was to ask them to CNAME over to your infrastructure, have them generate a private key and CSR, send the latter to a CA for signing, and then securely provide you with the key material (and again upon renewal). Or maybe you have engineering resources to spend and can build and maintain a solution to generate and securely store private keys, acquire and renew certificates, and push them to a CDN so TLS can be terminated in a performant manner (i.e., as close to your customers’ users as possible). Whichever route you choose, the technical complexity and burden of maintenance is high—either for your customers or your engineering and support teams.

SSL for SaaS was built with these difficulties in mind, and solves them with the simplicity that you and your customers expect. With SSL for SaaS, you can now send a single API call as part of your onboarding workflow and extend all the benefits of Cloudflare to these custom domains. All your customer has to do is add the initial CNAME into your domain.

Once the CNAME is in place and the API call is made, Cloudflare takes care of the rest. We’ll provision the hostname at our edge for forwarding on to your specified origin, acquire SSL certificates to enable HTTPS and HTTP/2, and sit in front of any DDoS or L7 attacks that may target your customers. All the benefits of Cloudflare, including CDN and content optimization, are extended to your customers’ hostnames without them having to do anything other than adding a DNS record.

Imagine that your company offers a support application that customers can white label and serve from their own domain. Whichever hostname they choose, e.g., support.yourcustomer.site or help.yourcustomer.site, you should instruct them to CNAME to a hostname of your choosing, e.g., whitelabel.yourcompany.ltd.

This white label hostname should be set up within your DNS dashboard as an A/AAAA or CNAME record pointing to your origin. Alternatively, you can use a pool of origins to load balance across. Once that record is in place, you can start instructing customers to CNAME their custom hostname to it. Or if your customers already have CNAME records in place, we can mirror that existing structure so that you don’t have to go back to your customers and request they make a change.

In the example below, we show how support.yourcustomer.site, a hostname of your customer with a CNAME pointing to whitelabel.yourcompany.ltd, can be provisioned and live at our edge with SSL certificates in just a couple of minutes.

$ dig CNAME +short support.yourcustomer.site
whitelabel.yourcompany.ltd.

Alternatively, you can add the CNAME after requesting certificate issuance, but it’s faster if you have it in place to begin with. If you need the certificates issued and live prior to your customer pointing their hostname over, consider using email-based validation.

With the CNAME in place, we show that HTTP connectivity to our origin is returned as expected and that HTTPS fails (again, expected) due to a certificate error. The reason the connection fails is that Cloudflare is serving the wildcard certificate for *.yourcompany.ltd, as you haven’t yet told us to get a certificate for app.yourcustomer.site.

$ curl http://support.yourcustomer.site
Hello, support.yourcustomer.site! This response is being served from whitelabel.yourcompany.ltd.

$ curl https://support.yourcustomer.site 2>&1|grep chain
curl: (60) SSL certificate problem: Invalid certificate chain

Now that the customer CNAME is in place, all you need to do is send us a single API call with the custom hostname to let us know we should expect to terminate TLS traffic there. We’ll take care of the rest.

curl -sXPOST -H "X-Auth-Key: [YOUR KEY]" -H "X-Auth-Email: [YOUR EMAIL]" -H "Content-Type: application/json" https://www.cloudflare.com/api/v4/zones/[YOUR ZONE ID]/custom_hostnames \
-d '
{ "hostname": "support.yourcustomer.site",                         
      "ssl": {
        "method":"http",
        "type":"dv"
      }
}' 

That’s it! Within a couple of minutes we’ll have validated that hostname with our CA partner, requested two types of certificates be issued—SHA-2/ECDSA signed for modern browsers that support elliptic curve cryptography and SHA-2/RSA to maintain compatibility with older browsers—and pushed it to all 110+ PoPs that comprise our edge.

$ curl https://app.yourcustomer.site
Hello, app.yourcustomer.site! This response is being served from whitelabel.yourcompany.ltd.

Your customer’s customers can now securely access their white labeled version of your application over HTTPS and take advantage of all the benefits it enables, such as the HTTP/2 protocol. These certificates and their keys are issued uniquely to your customer’s hostname (i.e., not co-located with any other customers), and served globally from a PoP close to your customer’s visitors.

Yes, we encourage you to use the Full or Strict SSL mode so that traffic sent to your origin utilizes HTTPS. This option can be configured in the Crypto tab of your zone. If you’re using Strict mode, you must ensure that the certificates on your origin contain a Subject Alternative Names (SAN) that matches your customer’s hostname, e.g. support.yourcustomer.site. Our Origin CA product can be used to generate these certificates for use with Strict mode.

Certificates are typically validated, issued, and pushed to our edge within a few minutes. You are able to monitor progress through the various states—Initializing, Pending Validation, Pending Issuance, Pending Deployment, Active—by making a GET call.

$ curl -sXGET -H "X-Auth-Key: [YOUR KEY]" -H "X-Auth-Email: [YOUR EMAIL]" https://www.cloudflare.com/api/v4/zones/[ZONE ID]/custom_hostnames?hostname=support.yourcustomer.site

{
  "result": {
    "id": "cdc2a12a-99b3-48b8-9039-ad1b48c639e5",
    "hostname": "support.yourcustomer.site",
    "ssl": {
      "id": "3463325d-8116-48f3-ab4e-a75fb9727326",
      "type": "dv",
      "method": "http",
      "status": "active"
    }
  },
  "success": true
}

No, we take care of all of this for you. The certificates we issue are valid for one full year (365 days) and will be renewed automatically at least 30 days prior to expiration. These certificates are uniquely issued in your customer’s hostname and, so as long as the CNAME is still in place, we can continue to easily renew by demonstrating “domain validation control” of that hostname. If the customer has churned, we encourage you to send us a DELETE request so we can pull the certificate from the edge and not attempt to renew.

With the exception of protecting your customers’ DNS infrastructure (unless they’re also using us for authoritative nameservice), the short answer is: all of them. Once their traffic is pointed to your white label hostname, we are able to provide our industry leading DDoS protection, CDN, WAF, HTTP/2, load balancing, and more.

These days not providing SSL for customers’ hostnames puts you (and them) at a competitive disadvantage. Besides protecting website visitors’ privacy and preventing unscrupulous ISPs or adversaries from modifying your application in transit, HTTPS delivers meaningful benefits that result in higher SEO and discoverability; from a rankings perspective, Google penalizes sites that don’t have HTTPS as well as sites that load slowly. Using SSL for SaaS is the easiest way to make your customers sites accessible via HTTPS and consequently reduce page load time by enabling HTTP/2. Reduced page load time also results in higher conversion rates.

Additionally, because SSL for SaaS is built on Cloudflare’s industry leading SSL/TLS implementation, your customers will benefit from all of the work we’ve done to make HTTPS fast, secure, and reliable such as deploying OCSP stapling, implementing TLS 1.3 (and 0-RTT), and optimizing TLS over TCP. Most importantly, by terminating these TLS connections as physically close to your customers as possible (as opposed to directly on your origin), your customers will benefit from the most interconnected network on the internet.

In some cases, you may have already pieced together a solution internally based on customer provided key material. Or your customer is using their desired hostname with a competitor (or internal solution) that provides HTTPS and cannot tolerate a short maintenance window.

For these cases, we have extended the two alternative “pre-validation” methods available in Dedicated Certificates to our SSL for SaaS offering: email and CNAME. Simply change the SSL method in the API call above from “http” to “email” or “cname” and send the request. See the API documentation for more information.

An email will be sent to the WHOIS contacts at your customer’s domain with a link to a simple page that we host. (This page can optionally be branded and hosted on your domain.) Once the “Approve” button is clicked, we’ll issue the certificate and push it to our edge automatically.

The other alternative method, CNAME token, is typically used when you control DNS for the vanity names (some of our SaaS customers, especially those providing website building and hosting services, allow the custom domain to be registered as part of the workflow).

Lastly, you are free to serve the HTTP token returned by the “http” validation method on your origin (instead of letting us insert it during the reverse proxy) and our automated retry queue will detect it once it is in place. If you’d like to tell us once it’s in place and have us retry immediately, you can always send a PATCH to the endpoint with the same SSL body as you sent during POST and we’ll immediately check for it.

Any SaaS application that allows customers to “bring your own domain” should be a great fit for SSL for SaaS. Some examples:

• Content management solutions such as generic website builders, blogging and static hosting platforms, image and photo sharing sites, and industry-specific site builders, e.g., education, healthcare, real estate, wedding, etc.

• eCommerce platforms that facilitate the selling of goods or services online.

• Web portals such as support, collaboration, and marketing/landing sites.

• Platform-as-a-service companies that allow customers to serve applications using their own hostname.

Sure, it’s definitely possible. But before doing so, make sure you have answers to the following questions:

From how many locations around the world will I be able to terminate TLS? What sort of performance will my customers see?Acquiring certificates is easy when compared with distributing them around the world and making them available as close to your customers’ visitors as possible. The further a visitor’s request has to travel, the slower the page load time will be. With TLS 1.2 an initial TLS handshake requires 2 round trips; if this handshake can only end up at a few locations, performance will suffer (unless all users are physically close to those locations and routed appropriately).

What happens if my customer gets DDoS’ed? How will this impact my infrastructure? When serving as your own frontline TLS termination point, all traffic destined for your customers’ hostnames will end up at your network perimeter. If a customer is under attack and this traffic exceeds your capacity, other customers may suffer.Terminating your customers’ traffic at our edge allows our DDoS protection services to handle attacks of any size, passing only legitimate traffic to your origin. We recommend that you install a certificate on your origin and configure the origin requests to utilize TLS.

How will I securely store and use my customers’ private keys? Private keys need to be stored securely, encrypted whenever at rest, and never written to disk in plaintext. Encrypting them is easy, but decrypting them on the fly is hard as it either requires manual effort or considerable engineering work.Cloudflare has experience generating and protecting private keys for millions of domains through our Universal SSL, Dedicated Certificates, and (now) SSL for SaaS products.

Does my HTTPS offering (whether from origin or another provider) support the performance-critical functionality enumerated on sites like istlsfastyet.com? If you’re rolling your own TLS configuration, make sure that you support all the extensions and related enhancements that make TLS fast and secure such as TLS 1.3 and HTTP/2 (enabled via the ALPN TLS extension).

What will I do if my CA encounters issues? Can my CA support my scale? When your implementation calls for onboarding large numbers of customers in an automated fashion, ensure that you’re able to failover to a different CA if one has issues or cannot keep up with the scale of your requests.

How often must I renew? What if something goes wrong? If you are issuing short-lived certificates and must renew frequently, you should make sure that this renewal process is monitored and maintained. HSTS settings may prevent a website from being loaded if the certificate has expired.

What is my plan for reissuing en masse if the next Heartbleed occurs? Related to renewals are reissuances in light of security concerns. If you were running an OpenSSL-based crypto stack when Heartbleed occurred, you needed to regenerate all of your keys and request reissuance of certificates.

If you’re not already a Cloudflare customer, give us your name and contact info and someone on our team will reach out to you; be sure to mention SSL for SaaS in the request. If you’re an existing Cloudflare customer, ask your Customer Success Manager.

CloudFlare is headed to the Interactive portion of SXSW in Austin from March 7-11, 2014. We are very excited to share some of the knowledge and experiences we’ve gained since our CloudFlare journey began. We have five, hot topic panel submissions that are in the running, so if any of the topics below sound interesting, cast your vote today.

About the 2014 SXSW PanelPicker:The 2014 SXSW PanelPicker public voting ends on Friday, September 6 at 11:59PM CT. PanelPicker voting counts for 30% of a sessions acceptance to SXSW.

NSA and the Future of Web Users and Web CompaniesMatthew Prince, Co-founder and CEO at CloudFlare, will join a panel with other industry experts to engage in a frank discussion about the NSA, online surveillance, and the privacy expectations from the perspective of both web users and web companies.

Movies and Music: Always Online EntertainmentNick Sullivan, a Systems Engineer at CloudFlare, put together a panel of experts, comprised of a variety of engineers who have all worked in the trenches for companies Rdio, SoundCloud, Apple and Netflix, to discuss the ins and outs of running a network built to scale for streaming and major releases.

Recruit the Best: Practical Tips to Build a TeamWhether you are a startup, small business or a manager at a large organization, finding and retaining the best talent is critical to your success. Michelle Zatlyn, Co-founder and Head of User Experience at CloudFlare will provide her insights and practical tips for building a team.

How a Partnership Can Make or Break Your BusinessThis duo presentation featuring Maria Karaivanova, head of Strategic Partnerships at CloudFlare, and Bill Lapcevic, VP of Business Development at New Relic, will cover how to build partnerships that rock, keeping you, your partners and your customers happy and thriving. Learn from these industry experts as they discuss the good, the bad, and the ugly of architecting large-scale partnerships.

Why, How, and When to Build a SaaS Sales TeamChris Merritt, Sales Lead at CloudFlare, is joining Jamie Sutherland of Xero and Lars Leckie of Hummer Winblad in a session that will draw on sales leaders and experts that have built both inside and field sales teams. They will dig into the vagaries of building and running a sales team including lessons from recruiting, hiring, commission structures, and more.