Security
Overview of Webiny security strategy.
- How we approach security
- Additional security recommendations
About
If we don’t have security, we can’t really say we have a good product. Although Webiny is a self-hosted solution, meaning you control your security, it’s still important for us to provide an overview of our security practices. This will make you acquainted with our approach, and will make it easier to align your implementation to some of the best practices we established.
This being an overview article, it will provide the main elements and a clear distinction in terms of the security responsibilities that are on your end in comparison to the ones being handled by Webiny.
We’ve structured the article into 4 main sections:
- Codebase - how we ensure our codebase isn’t compromised
- Infrastructure - how the security layer is implemented as part of the infrastructure that Webiny deploys
- Application - how Webiny protects the application from unauthorized access
- Data - how your data is stored and secured
Codebase
Webiny, being an open-source project, our code is public, and with that comes great responsibility for the security aspects around it.
Our code-base is regularly scanned for vulnerabilities by CodeQL 
—the world’s most powerful code analysis engine.
All the 3rd party dependencies we use are scanned via Dependabot .
No single change made to our codebase skips these checks.
Infrastructure
Webiny is designed to run on top of the AWS cloud at the moment, with support for other clouds coming at a later point.
The serverless services Webiny uses as part of its architecture are fault-tolerant by design. The only exception is Elasticsearch. In the Webiny production deployment stack, Elasticsearch is automatically deployed in multiple AZs, making it highly-available. Any public access, in both VPC and non-VPC deployment is restricted.
With Webiny there are zero servers you need to manage, reducing the risk of a security breach due to misconfiguration. Serverless services are tested by the cloud provider against all forms of attacks across millions of customers, giving your confidence in their security. Serverless services in general reduce the potential attack vectors that can be used against your application.
Webiny ships with 2 infrastructure stacks by default, a development one and a production one.
We highly recommend that you use the production stack for all your projects running production traffic.
The production stack by default is deployed inside a private VPC preventing direct access to resources like DynamoDB and the Elasticsearch database. Keeping your data safe.
Additional security improvements you can make to your project:
- Firewall: Webiny intentionally deploys a CloudFront web distribution in front of an API Gateway. This setup allows you to place a web application firewall to all incoming requests for added security.
Application
Webiny is built to support different authentication mechanisms. Out of the box, it is configured to work with AWS Cognito , an enterprise-grade, battle-tested identity provider. The framework, however, supports any identity provider, by means of plugins.
Webiny draws a very clear line between authentication and authorization. We rely on third-party IdPs for authentication and use a very flexible system of permissions for authorization.
Authorization is usually very closely tied to business logic, so using scopes from the JWT, or simple string-based roles is not enough for complex business applications. To allow different types of integration, we provide a very thin security framework, based on plugins. On top of that, we define permissions as rich objects with different application-related properties.
Data
Because Webiny is self-hosted and under the MIT license, your data stays within your cloud infrastructure. In practice, this usually means there is no need for any legal, data compliance or GDPR changes to be made when adopting Webiny.
When it comes to storing your data, it’s saved inside a DynamoDB database and Elasticsearch, and files are stored inside an S3 bucket.
All the data inside DynamoDB is encrypted in transit and at rest by default.
All the data inside Elasticsearch is encrypted at transit only, by default.
For production cases, we recommend you also encrypt data at rest in Elasticsearch. Ensure you have a proper key management strategy in place beforehand otherwise it could lead to making your data inaccessible. For more info visit: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/encryption-at-rest.html
The data inside S3 bucket by default is not encrypted, is set to be publicly accessible and versioning is turned off. Public access is only allowed on the list command. Write operations need to be signed with a security token to be allowed. We advise that you adjust these parameters to the needs of your project accordingly.
If needed you can restrict access to the S3 buckets by modifying the ACL policy inside the Pulumi infrastructure files. At the moment if you make the S3 bucket private to non-authorized users, images embedded in the Page Builder and other places will not be displayed and potentially the Admin app might be made inaccessible. Please contact us in case you need to make your S3 completely private.
FAQ
Can I Use a Different Identity Provider?
Yes, absolutely. The default IdP implementation contains a set of plugins on the API and React sides. All you need to do is follow the same principle and implement your own plugins that will work with the IdP of your choice.
Can I Roll My Own Authentication System Instead of Using a Third-Party IdP?
We don’t recommend it, but yes, you can. Following the same implementation strategy that comes with Webiny by default, you can create all kinds of authentication mechanisms.