On July 29th at 00:00 UTC, Fastly was notified by a customer (customer X) that a single log line intended for a different customer (customer Y) was received by customer X’s log system. Fastly promptly began to investigate and determined that when a complex series of conditions occur, a log line may be misrouted to an incorrect logging service. We were able to trace the root cause to an error in logic introduced by Fastly to improve performance in April 2012. This single report from one customer is the only instance that Fastly is aware of, where all necessary conditions aligned simultaneously in eight years.

Security has always been a part of Fastly’s DNA, not just within products, but in our vision of trust and safety as a modern platform. Today, we are pleased to announce that we have announced our intent to acquire Signal Sciences.

Fastly CISO Mike Johnson and Brave Software Senior DevOps Engineer Ben Kero share their practical advice for cementing more holistic security practices within your CI/CD pipeline.

Fastly was notified of the issue on May 21, 2020 13:30 UTC. Fastly immediately launched an investigation, identifying which origin servers responded with a test port number in the redirect response, in order to understand the vulnerability and possible solutions. After the investigation, Fastly first notified potentially affected customers on July 15, 2020 at 04:30 UTC. The vulnerability is a variant of a [previously reported vulnerability](https://www.fastly.com/security-advisories/cache-poisoning-leveraging-various-x-headers), and ultimately the result of constructing cacheable origin responses based on user-defined data. The issue occurs when an attacker issues an HTTPS request and specifies within the Host header a port number that is not actually being used for any services. It is possible to cache a resource in such a way as to deny future requests from being serviced properly.

If you’re evaluating web application security tools exclusively for their security requirements, you may be missing one of the most essential opportunities to successfully grow your secure DevOps culture: developer-centricity.

Fastly's heritage of security runs deep — far beyond our portfolio of web application and API security products. Our philosophy of developer empowerment, focus on community, and values-driven culture each contribute to our security DNA in an important way. And we'd like to tell you how.

TLS 1.3 is now available for Fastly customers. The newest version of the TLS protocol, TLS 1.3 is designed to improve the performance and security of traffic served over HTTPS.

Building our own compiler toolchain allows Compute to be both performant and secure. It also means we have to bring developers’ most-loved language into the fold in the right way.

Using integrations with BigQuery and Looker, we’ve created 15 chart templates that help you effectively monitor security events on your sites and applications, in real time.

The newest version of Transport Layer Security, TLS 1.3, is faster, more robust, and more responsive than ever before. Explore three ways it will help HTTPS protect origin names for improved confidentiality.

Integrating security into your DevOps cycle isn’t something that happens overnight. Here are five tips for building a culture in which secure DevOps can thrive, enabling your team to build secure apps quickly.

Learn about the technical details of SSRF, how it was utilized in the Capital One breach, why it’s so critical to understand for today’s cloud-hosted web apps, and how organizations can protect their web applications and APIs from such attacks.

Fastly now offers two new TLS services for the trust, flexibility, and scalability customers need to bring the best of the internet to life.

The 4.2 release of the Fastly agent introduces WebSocket traffic inspection, enabling customers to extend the coverage of applications, APIs, and microservices protected by Fastly’s Next-Gen WAF to apps and services that utilize the WebSockets protocol.

On November 11, 2019, at 21:57 UTC, Fastly deployed a new build of its HTTP/2 termination software to two Fastly cache servers in the Minneapolis-St.Paul (STP) data center. This build contained a processing flaw involving connection re-use between internal Fastly systems (unrelated to HTTP/2 multiplexing), and caused some incoming HTTP/2 requests for Fastly customers’ services to potentially be routed incorrectly to a group of up to 20 different Fastly customers’ services and origins. This led to some client request data being delivered to, and a response returned by, an incorrect customer origin. The customers whose origins erroneously received these requests may have logged the incorrectly-routed request data. Fastly was first notified by a customer of a client error on November 12, 2019, at 23:07 UTC. On November 13, 2019, at 00:50 UTC, all customer traffic was diverted away from the affected data center. Fastly immediately commenced an investigation, and on November 14, 2019, at 00:31 UTC, we validated the presence of incorrectly routed request data in a customer’s logs. We estimate this flaw affected 0.00016% of our global request traffic during the 27-hour period. It is unlikely that affected client requests came from outside of North America. Because Fastly does not store customer log data, we are not able to say with certainty if an affected request was incorrectly routed.

With attackers using publicly available lists of compromised passwords in an attempt to steal accounts, proof of work is a good way to slow the attackers down.

Security and development teams have a responsibility to secure customer data at the web application layer and stop attackers and Fastly's Next-Gen WAF can help.

This post focuses on the key authentication events that financial services organizations should monitor to defend against account takeovers. We’ll also illustrate how utilizing a threshold-based approach enables organizations to identify irregular request patterns to spot fraudulent authentication and account activity.

Sigsci-sounds monitor attack and anomaly data and will play a sound for each type of attack or anomaly.

Today we’re announcing two new offerings on the Fastly platform: Platform TLS and Subscriber Provided Prefix. Both empower companies to provide fast, secure web experiences to their customers and end-users, while reducing the workload on their own internal teams. Large companies, such as those offering mass hosting or managing multi-brand portfolios, can now quickly and easily manage hundreds of thousands of certificates in bulk.