# Tasks accept scripts and inputs that look like attacks, and WAF exceptions take * inside the path

> Creating or editing a task through dash.openwaf.dev no longer gets a 403 from the edge WAF when the script, input or goal looks like shell, SQL or HTML. A * before the end of a WAF exception path stands for one path segment.

Creating or editing a task through `dash.openwaf.dev` (dashboard, API, CLI) answered `403` from our own edge WAF when the `script`, the `input` or the agent `goal` contained text that looks like a shell command, SQL, HTML or a file path, such as `cat /etc/passwd` in an input; even the script of the [quickstart](https://developers.openwaf.dev/tasks/quickstart-script/) was refused. On the task routes (`/v1/orgs/{org}/tasks` and below) the WAF now skips the injection rules that such text triggers; they need a session or a token, and the API validates every field. The other WAF rules, the shields and the rest of the API keep their inspection.

`script` is accepted as is; [`script_base64`](https://developers.openwaf.dev/tasks/reference/#task) keeps working but is no longer needed.

The fix uses a new form of [WAF exception](https://developers.openwaf.dev/waf/waf-exceptions/#path-pattern) path: a `*` before the end of `path_pattern` stands for any characters except `/`, so `/v1/orgs/*/tasks` covers that route for every organization and nothing else under `/v1/orgs/`. A trailing `*` is still a prefix.