|Organizers||Franziska Buehler Franziska Buehler|
|Participants||Tanya Janca Tanya Janca , Daniel Garcia (cr0hn) Daniel Garcia (cr0hn) , Felipe Zipitria Felipe Zipitria|
A Web Application Firewall may cause fear it does not fit into DevOps methodology, because a WAF can also block an application‘s legitimate traffic.
In this user-session we will see a Continuous Integration pipeline with automated applications tests. The tests are performed against the application Pixi (OWASP DevSlop) with the WAF ModSecurity with the OWASP ModSecurity Core Rule Set 3 in front of the application.
A WAF is an additinal layer of defense against common web application attacks like those described by OWASP Top Ten!
We don‘t want to miss a WAF only because we fear it!
- Web Application Firewall
- ModSecurity and OWASP ModSecurity Core Rule Set
We will put the WAF ModSecurity with the OWASP ModSecurity Core Rule Set 3 in front of Pixi in CircleCI. We let application tests automatically test the application with a WAF at every commit of a code change.
- What is a WAF, what does a WAF do?
- What is ModSecurity and the OWASP ModSecurity Core Rule Set 3?
- CRS 3 Installation
- CRS 3 in Docker Container (Apache Reverse Proxy, CRS variables)
- Quick Intro into CircleCI (Integration in GitHub)
- Quick Intro into Testcafe application tests of Pixi
- ModSecDevOps (WAF in pipeline)
- Show CircleCI PoC configuration
- Show CircleCI CRS3 Pixi Demo
- Show ModSecurity Tuning in CircleCI configuration
More security by adding the OWASP ModSecurity Core Rule Set in front of Pixi!
The CircleCI configuration and the Core Rule Set Docker Container can be taken as a free proof of concept.
Register as participant
To register as participant add
Adding CRS3 and Pixi to CircleCI pipeline to either:
sessionsmetadata field from your participant's page (find your participant page and look for the edit link).
- or the
participantsmetadata field from this git session page
Back to list of all User Sessions