Cannot switch from JSON editor to visual editor.
A rule that contains nested statements or more than 5 statements is not supported. You must view the rule in the JSON viewer.

That means once your rules get a little more complex, with nested AND/OR statements or more than five conditions, the visual editor in AWS just throws up its hands. You’re left staring at raw JSON, which isn’t exactly easy to parse at a glance.

Why This Is a Problem

• Hard to understand: Nested JSON statements can get messy very quickly.

• Hard to review: Security and DevOps teams often need a quick way to review rules before deploying.

• Hard to debug: If something doesn’t behave as expected, reading JSON doesn’t make troubleshooting easier.

In short: AWS gives us power, but not clarity.

Enter WAFViz

That’s why I built WAFViz, a simple tool to visualize AWS WAF rules.

Instead of drowning in JSON, WAFViz turns your rules into a clear, human-friendly visualization. You can:

• Upload or paste your JSON rule.

• See the hierarchy of AND/OR/NOT conditions.

• Share visualizations with your team for reviews.

No more guessing what a deeply nested JSON statement really means.

Example: Before and After

Before: A wall of JSON that only the person who wrote it can decipher.

After: Visualization where you can instantly see what conditions are combined and how.

This makes security reviews faster, collaboration easier, and debugging far less painful.

Try It Out

You can check it out here 👉 https://wafviz.ardd.cloud

If you’re working with AWS WAF rules in JSON, this tool will save you time and sanity.

What’s Next

I’m planning to expand WAFViz with features like:

• Import directly from AWS.

• Export visual diagrams as PNG/PDF for documentation.

• Collaboration mode for teams.

Feedback is super welcome… feel free to reach out and let me know how WAFViz can be more useful for you.

At first glance, it looks harmless, just part of Next.js’ internal routing logic. But under the hood, it can carry more than you would expect.

What is Next-Router-State-Tree?

Next.js uses the Next-Router-State-Tree header to pass routing state between server and client for navigation and hydration. In theory, it is meant for internal use only. In practice, it is leaked in network requests and visible in server logs, proxies, or observability tools.

Why This Is a Problem

• URL Fragments and Query Data
  The header may contain the full requested URL, including fragments (#hash) or sensitive query params. Normally, fragments never leave the browser, but here they get serialized into this header, meaning data you thought was client-only can unexpectedly travel across the wire.

• Logs and Monitoring
  If your app is deployed behind a reverse proxy, CDN, or observability platform, this header is often logged. Suddenly, internal state, routing data, or sensitive identifiers become part of access logs you do not control.

• Attack Surface
  Attackers could potentially harvest extra information from leaked headers if they gain access to logs or intercept requests. Even if the data is not outright sensitive, it adds unnecessary exposure.

Example from dele.to

Here is an example link from dele.to:

https://dele.to/view/066d161a-5744-4904-8da3-bb7cbb3e07ba#wBPa77IW3/lKG/9dYGkke55cWGncciYqiKm8wJzYZMo=

next-router-state-tree looks like this:

%5B%22%22%2C%7B%22children%22%3A%5B%22view%22%2C%7B%22children%22%3A%5B%5B%22id%22%2C%221b0c4494-0899-4bb5-b6c9-66cdbbc23ad0%22%2C%22d%22%5D%2C%7B%22children%22%3A%5B%22__PAGE__%22%2C%7B%7D%2C%22%2Fview%2F1b0c4494-0899-4bb5-b6c9-66cdbbc23ad0%233ZHX%2F64lX9TrTx5KI1hgMrJzdgbwoRcHTQBxpcYbBQc%3D%22%2C%22refresh%22%5D%7D%5D%7D%5D%7D%2Cnull%2Cnull%2Ctrue%5D

which after decoding (included #fragment):

["",{"children":["view",{"children":[["id","1b0c4494-0899-4bb5-b6c9-66cdbbc23ad0","d"],{"children":["__PAGE__",{},"/view/1b0c4494-0899-4bb5-b6c9-66cdbbc23ad0#3ZHX/64lX9TrTx5KI1hgMrJzdgbwoRcHTQBxpcYbBQc=","refresh"]}]}]},null,null,true]

The secret after # is meant to remain in the browser only. But with Next-Router-State-Tree, that fragment ends up in the request header.

This means:

• CDNs log it

• Backends may store it

• Debugging tools might capture it

In short, sensitive data can leak into places it was never meant to go.

The Bigger Issue: No Official Fix

Here is the tricky part: Next.js does not currently offer any way to disable the Next-Router-State-Tree header. It is baked into the framework.

The only option is to patch the package yourself, either by modifying Next.js internals or using a custom fork. For production apps that rely on fragments or handle sensitive routing, this is a serious limitation.

As part of addressing this in dele.to, we published a workaround patch in PR #7. This removes the header in self-hosted deployments until a proper framework-level fix exists.

Issue has been opened in Next.js for actual fix

Mitigations Until Then

• Do not rely on fragments for sensitive data such as tokens or IDs

• Strip the header at your proxy or load balancer level (for example, drop it in Nginx or Cloudflare)

• Audit your logs to make sure fragments are not being stored

• Apply patches like PR #7 to remove the header in self-hosted setups

• Push for framework changes because this header should never serialize fragments in the first place

Closing Thoughts

This issue was discovered in the course of building dele.to, but it is relevant to anyone using Next.js in production. It is a reminder that “internal” headers are not always internal once they leave the browser.

Frameworks that ship extra state in headers risk leaking information developers never intended to expose. Until Next.js provides a safe toggle, the only reliable option is to patch the package or strip the header manually.

If you are using Next.js, take a moment to inspect your traffic. You might be surprised what is riding along with your requests.

Thanks to accountless and security researcher Cassie Heart @ Quilibrium.com for finding this issue. Original discussion happened on Farcaster.

Let's touch base...

What is Cloudflare Pages ?

Cloudflare Pages radically simplifies the process of developing and deploying sites by taking care of all the tedious parts of web development. (read more)

Concept

CF Pages as a concept is not new. For example, Github Pages is essentially exactly the same thing. There's additionally Netlify, CloudFront + S3, Vercel, and GitLab Pages. So you could ask yourself "What's the point of using one more platform?"

Let's list some reasons:

• In one dashboard you will find everything DNS management, Workers (Serverless functions in CF), WAF, Security Center, Page rules, and many more great things for your website!
• Quick integration with GitHub and GitLab repos, fast builds, and awesome CDN!
• Free plan is lit! (Unlimited sites, bandwidth, requests !!! yeah, you heard it right!)

Problem

Assuming you already have set up CF Pages and just one thing of the puzzle is missing, Slack notifications!

Currently, there is no direct integration for Slack notifications on CF Pages like other services such as Netlify and also there are some community posts like this one asking for solution https://community.cloudflare.com/t/get-slack-webhook-when-pages-build-finished-cloudflare-pages/311019

Solution

Without further ado let's get our hands dirty !

There are plenty of blog posts on how to create CF Pages project so I will not include that in this post.

In order to achieve this I've published a Cloudflare Pages Slack Notification GitHub action

https://github.com/marketplace/actions/cloudflare-pages-slack-notification

Let's analyze it a bit how this action works:

• It is built on top of CF Pages Await by WalshyDev
• Uses slack-notify npm package

Whenever there is a new push to GitHub it triggers GitHub action pipeline where it waits for deployment to finish by listening to Cloudflare API Read more

If the deployment fails it will show a Slack message like this:

(failed build notification)

If deployment is successful shows message as: (deployment successful)

It also adds deployments directly in GitHub

Usage

Let's first add GitHub secrets:

• CF_ACCOUNT_EMAIL - Cloudflare account email
• CF_API_KEY - Global API key (get it here https://dash.cloudflare.com/profile/api-tokens)
• CF_ACC_ID - Cloudflare account ID (from dashboard URL https://dash.cloudflare.com/180f4xxxxxxxxxx or go to Workers and on the right is Account ID)
• CF_PROJECT - Cloudflare Pages project name (e.g test-dashboard)
• SLACK_WEBHOOK - Slack Incoming Webhook https://hooks.slack.com/....
• GITHUB_TOKEN - It will be automatically fetched by pipeline - no need to be added, this is used to add deployments on GH as per the screenshot above.

Verify added secrets:

Let's start creating GitHub action configuration yml.

Create a .github/workflows/action.yml file and add the following

name: Send Slack notifications
on: 
  push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Send Slack deployment notifications
      uses: arddluma/cloudflare-pages-slack-notification@v2.2
      with:
        accountEmail: ${{ secrets.CF_ACCOUNT_EMAIL  }}
        apiKey: ${{ secrets.CF_API_KEY  }}
        accountId: ${{ secrets.CF_ACC_ID  }}
        project: ${{ secrets.CF_PROJECT  }}
        githubToken: ${{ secrets.GITHUB_TOKEN }}
        slackWebHook: ${{ secrets.SLACK_WEBHOOK  }}

After running the pipeline you should get notifications on Slack like this:

And..... Voila 🎉

That's it! You now have deployment notifications on Slack! Enjoy :)

Thanks for reading!

Introduction

We all know how difficult is to manage and rotate AWS IAM keys, there are a lot of tools out there that can help you manage your keys easly but in this blog post I will tell you about the process and introduce you a new tool for key rotation.

Let's first touch base...

What is IAM

AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.

Key rotation

Changing access keys (which consist of an access key ID and a secret access key) on a regular schedule is a well-known security best practice because it shortens the period an access key is active and therefore reduces the business impact if they are compromised.(reference)

To manually rotate keys AWS has documented steps needed to follow but this is a bit pain...

To rotate access keys, you should follow these steps:

Create a second access key in addition to the one in use.
Update all your applications to use the new access key and validate that the applications are working.
Change the state of the previous access key to inactive.
Validate that your applications are still working as expected.
Delete the inactive access key.

To get rid of all of this pain let me introduce you to the aws-iam-key-rotation tool that will help rotation your keys automagically

Let's dig a bit deeper...

How does it work?

This script uses AWS CLI to rotate keys, in order to work you should add aws profile name and IAM user as parameter.

Prerequisites

• awscli (https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)
• jq (sudo apt-get install -y jq or brew install jq)

Usage:

./aws-iam-key-rotation.sh aws-cli-profile iam-user-name

There are two cases covered by script

1. If user has only one key configured
2. If user has two keys configured

Screenshots:

If user has only 1 key configured

It will create new key - check if key works properly, set it up on existing aws cli profile and delete the old one.

If user has 2 keys configured

It will deactivate and delete the oldest key.

Automating the process

In this example I will be using crontab to schedule script to run every day at 00:00

1. First run crontab -e
2. At the beginning of the crontab file add this line SHELL=/bin/bash
3. 0 0 * * * /path/to/script/aws-iam-key-rotation.sh <aws-cli-profile> <iam-user-name> (if you want to see the logs of each triggered job you can add this >> /path/to/log/file at the end of command) E.g 0 0 * * * /path/to/script/aws-iam-key-rotation.sh <aws-cli-profile> <iam-user-name> >> /path/to/log/file
4. Save it and wait for magic to happen :)

Hope you enjoyed reading this blog post :)

Thank you !

What is GitLab Pages

With GitLab Pages, you can publish static websites directly from a repository to GitLab for free. You can publish static files such as HTML, Jekyll, and CRA app. It’s the same concept as GitHub Pages if you’ve tried it before.

What is Create React App

Create React App is a comfortable environment for learning React, and is the best way to start building a new single-page application in React.

Now… Let’s get our hands dirty …

The First step, we need to create a repository on GitLab. The Name of the repo should be like this: (username).gitlab.io

Your username should not include dots e.g ardd.cloud because of the HTTP protocol, when it’s deployed it will be sub-subdomain e.g ardd.cloud.github.io

Let’s create our repo first…

Now, we need to initiate our simple create single-page React app. Let’s start by installing npm install -g create-react-app or using yarn yarn global add create-react-app.

Run: npm init react-app my-app or yarn create react-app my-app

Go to my-app and run npm start or yarn start and it should look like this:

To edit you need to go to src/App.js file.

After editing we need to push changes to GitLab repo using those commands:

git init
git remote add origin git@gitlab.com:username/username.gitlab.io.git
git add .
git commit -m "Initial commit"
git push -u origin master

Now we need to edit Pages settings on repository settings. Go to the repo that you’ve created before, and then go to Settings / General / Visibility, project features, permissions click expand, and select Everyoneon the dropdown list and hit Save changes.`

To deploy we need to add .gitlab-ci.ymlconfiguration, to do this we can add locally and then push through git but we can also add it from console. Go to Project Overview and click Set up CI/CD .gitlab-ci.yml should look like this:

image: node:10.16.1 #specify your node version

pages:
  stage: deploy
  script:
  - yarn cache clean -f
  - yarn
  - unset CI
  - yarn run build
  - rm -rf public
  - mv build public
  artifacts:
    paths:
    - public
  only:
  - master

You can get it on GitHub

Note: If you are running npm as a package manager then config should look like this:

image: node:10.16.1 #specify your node version

pages:
  stage: deploy
  script:
  - npm cache clear --force
  - npm install
  - unset CI
  - npm run build
  - rm -rf public
  - mv build public
  artifacts:
    paths:
    - public
  only:
  - master

Commit changes and go to CI/CD / Pipelines you’ll see the pipeline running. Wait a bit and you will get Job Succeded

**Yayyyy, you’ve deployed successfuly to GitLab Pages. To get your URL go to Settings / Pages.

View our page: ardd-cloud.gitlab.io

yayy

Thank you !