# 4.3 Query String Filtering

#### 📖 Overview

The **Query String Filtering** module enables you to control and sanitize the **query parameters** (GET variables) attached to incoming requests.

By defining allowed or blocked query strings on a **per-path basis**, you can protect sensitive endpoints, APIs, and web forms against tampering, injection, or unexpected behavior.

This adds a powerful application-layer control that complements WAF rules and general request validations.

***

#### 🎯 Purpose

* Allow only **expected parameters** on specific pages.
* Block unexpected or malicious parameters.
* Remove untrusted query parameters automatically.
* Harden API endpoints, authentication flows, and payment pages.

***

#### ✅ How It Works

You define rules specifying:

* **Target Page Path:**\
  (e.g., `/login`, `/api/user/info`, `/checkout`)
* **Allowed Query Keys:**\
  (e.g., `email`, `token`, `id`)

<figure><img src="/files/DaYimd8mCC3KIxVmiOVX" alt=""><figcaption></figcaption></figure>

When a request is made:

* Only the listed keys are allowed.
* Any additional parameters are either **removed** or **blocked** based on configuration.

***

#### 📋 Example

**Allowed Keys for `/login`**

* `email`
* `redirect_uri`

**Incoming Request:**

```
/login?email=user@example.com&admin=true
```

**Behavior:**

* `admin=true` is **removed** or **causes a block**, depending on rule setting.

***

#### 🛠️ Configuration Options

* **Allow Only These Keys:**\
  Block or strip any parameter not explicitly listed.
* **Action Mode:**
  * **Remove unauthorized arguments** silently
  * **Block the request** if unauthorized arguments are detected
* **Multiple Rules:**\
  Create multiple rules for different paths.

***

#### 🚀 Use Cases

| Scenario                           | Benefit                                  |
| ---------------------------------- | ---------------------------------------- |
| Protect login and signup endpoints | Prevent parameter injection              |
| Secure API requests                | Enforce strict parameter structure       |
| Harden payment callbacks           | Only allow signed, expected arguments    |
| Reduce attack surface              | Disallow noisy or unnecessary parameters |

***

#### 🧠 Best Practices

* **Whitelist only absolutely necessary parameters.**
* **Avoid allowing “debug”, “test”, or unused parameters** on production systems.
* **Combine Query String Filtering with WAF** to maximize protection.
* **Review URL patterns regularly** as your application evolves.

***

#### ⚙️ How to Add a Query String Filter

1. Go to **Security Rules > Query String Filtering**.
2. Click **Add New Rule**.
3. Enter the **Page Path**.
4. Define all **allowed query keys**.
5. Choose the **action** (Remove unauthorized / Block unauthorized).
6. Save the rule.

> 🛡️ The rule will be active immediately for all matching requests.

***

#### ⚡ Important Notes

* Query filtering happens **before** request routing to backend servers.
* Filtering is **case-sensitive** for parameter names.
* Be cautious on dynamic URLs where parameters may vary unexpectedly.

***

> 🎯 By enforcing strict query string structures, you prevent misuse, abuse, and accidental exposure of your application's internal logic.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.shieldsguard.com/getting-started/4.-security-rules/4.3-query-string-filtering.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.