As more and more developers and companies adopt serverless architecture, the likelihood of hackers exploiting these applications increases dramatically. The shared security model of cloud providers extends much further with serverless offerings, but application security is still the developer’s responsibility. There has been a lot of hype about #NoOPS with serverless environments 🤥, which is simply not true 😡. Many traditional applications are frontended with WAFs (web application firewalls), RASPs (runtime application self-protection), EPPs (endpoint protection platforms) and WSGs (web security gateways) that inspect incoming and outgoing traffic. These extra layers of protection can save developers from themselves when making common programming mistakes that would otherwise leave their applications vulnerable. With serverless, these all go away. 😳
Serverless makes it easy to deploy a function to the cloud and not think about the infrastructure it’s running on. While certainly convenient, this leaves many developers with a false sense of security. By relying too heavily on the cloud provider, and not coding defensively, developers can significantly reduce their overall security posture. As with any type of software, there are a myriad of attacks possible against serverless infrastructures. However, unlike traditional web applications, serverless architectures are “event-driven”. This means they can be triggered by a number of different sources with multiple formats and encodings, rendering WAFs useless and opening up a completely new attack vector…
In May the European Union’s General Data Protection Regulation goes into effect, two years after passage by the European Parliament. This radical new privacy law, which covers any business that processes information about EU residents, will dramatically affect the way data is collected, stored, and used, including for U.S. companies doing business abroad.
In the U.S., lawmakers are now circling waters bloodied by revelations regarding potential abuse of Facebook’s social media data, with CEO Mark Zuckerberg scheduled to testify on Capitol Hill this week about the “use and protection of user data.” Facebook’s woes, following continued reports of major data breaches at other leading companies, have amplified calls for GDPR-like legislation in the U.S.
This project intends to provide a complete description and re-implementation of the WhatsApp Web API, which will eventually lead to a custom client. WhatsApp Web internally works using WebSockets; this project does as well.
Many companies are suffering data breaches because attackers gain access to data in AWS S3 buckets. I don’t want to repeat all the news articles outlining all the S3 data breaches. A Google search will give many examples, and it seems like by the time I write this another one will be in the news. Instead, I’d like to jump to why these S3 bucket breaches are happening and how to securely store data in an S3 bucket.
Why spend time building things that you can buy or rent?
For those who have never heard of the term “BaaS” before, it stands for “Backend as a Service” and refers to third-party API services that can be integrated into your applications to build out specific functionality quickly.
For example, imagine how much work it’d take your team to build a single sign-on service for your product along with an admin interface for provisioning and managing user permissions. Sound like a pain? Well good news, there are plenty of services that you can drop-in to achieve this without writing a single line of server code.
In fact, these days there are a number of successful companies who have been able to produce compelling products with barely any of their own server-side code.
In this article, we’ll introduce five API service providers that address common features and take a look at how they work.
In this guide, you will set up a hardened, fully functional OAuth 2.0 (OAuth2) server. It will take you about ~15 minutes. This guide is for you, if you are looking to do something like in the gif on the right, or more specifically:
- You want to use OAuth2 for API security.
- You want to open up your API to third party developers like Dropbox, or GitHub.
- You want to become and identity provider like Google, Facebook, or Twitter.
- You need to federate (delegate) authentication or authorization.
We will use ORY Hydra (open source), a security-first OAuth2 and OpenID Connect server written in Golang.