PHPackages                             laruence/taint - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. laruence/taint

ActivePhp-ext

laruence/taint
==============

Taint is a PHP extension for detecting XSS codes (tainted strings).

6180124[17 issues](https://github.com/laruence/taint/issues)[3 PRs](https://github.com/laruence/taint/pulls)CCI passing

Since Aug 8Pushed yesterday43 watchersCompare

[ Source](https://github.com/laruence/taint)[ Packagist](https://packagist.org/packages/laruence/taint)[ RSS](/packages/laruence-taint/feed)WikiDiscussions master Synced today

READMEChangelogDependenciesVersions (1)Used By (0)

Taint
=====

[](#taint)

[![linux](https://github.com/laruence/taint/actions/workflows/linux.yml/badge.svg)](https://github.com/laruence/taint/actions/workflows/linux.yml)[![windows](https://github.com/laruence/taint/actions/workflows/windows.yml/badge.svg)](https://github.com/laruence/taint/actions/workflows/windows.yml)

A PHP extension to detect XSS codes(tainted strings). It can also be used to spot SQL injection vulnerabilities, shell injection, etc.

The idea comes from , and I implemented it as a PHP extension, so no core patch is needed.

Please do not enable this extension in production environments, since it will slow down your app.

> **EXPERIMENTAL.** Taint is a research-grade detection tool, not a security product. Detection coverage, warning behavior and INI settings may change between releases without any backward-compatibility guarantees.

Requirements
------------

[](#requirements)

- PHP 8.0+ (`master` branch)
- PHP 7.x ([php7 branch](https://github.com/laruence/taint/tree/php7), taint 2.1.x releases)
- PHP 5.x ([php5 branch](https://github.com/laruence/taint/tree/php5), taint 1.x releases)

How it works
------------

[](#how-it-works)

Strings received from user input are marked "tainted" at request startup, and the mark is tracked through string operations. When a tainted string reaches a dangerous sink (output, SQL query, shell command, file path, ...), taint raises a warning.

Taint sources are: `$_GET`, `$_POST` and `$_COOKIE`.

Design philosophy
-----------------

[](#design-philosophy)

- **One bit, no context.** The taint mark is a single bit stored on the string itself (`zend_string`), not on the variable. It carries no information about which context (HTML, SQL, shell, ...) the string will end up in, and taint never tries to analyze whether a value is "actually safe" for that context.
- **Over-report rather than stay silent.** Concatenation, interpolation and a whitelist of data-preserving string functions propagate the mark even when the result happens to be harmless. A warning means "user input reached this sink, go look at it", not "definitely exploitable". Noisy-but-auditable beats clever-but-silent.
- **Everything else clears the mark.** Any function taint does not explicitly understand — including escaping helpers like `htmlspecialchars()` — returns a fresh, unmarked string. Checks stay shallow on purpose: only top-level string arguments of sink calls are inspected.
- **Zero core changes.** The whole mechanism is implemented with user opcode handlers and internal-function handler swaps, so taint is a normal PECL extension that works on a stock PHP build. The price is that it conflicts with other extensions that hook the executor (see NOTE below).
- **Report, don't block.** Taint only raises warnings; it never alters or rejects data. It is a bug-finding instrument for developers, not a runtime defense.

When to use
-----------

[](#when-to-use)

Good fits:

- Auditing an existing codebase: run your test suite, or drive the app manually, with taint enabled, and the warnings will point out paths where raw user input reaches an output, SQL, shell, filesystem or code-execution sink.
- Regression checks in development/QA environments before a release — XSS, SQL injection, command injection, file-path injection.
- Understanding how user input flows through an unfamiliar application.

Not a good fit:

- **Production.** The instrumentation slows every request down, conflicts with opcache/xdebug, and the warnings themselves may leak request data into logs.
- **Runtime defense / WAF.** Taint reports, it does not block, and its context-independent bit cannot decide whether a value is really safe.
- **A substitute for escaping and parameterization.** A clean run means "nothing taint could see", never "provably secure".

NOTE
----

[](#note)

Taint works by installing user opcode handlers and swapping internal function handlers, so it conflicts with extensions that hook the executor or opcode handlers as well, most notably **opcache** and **xdebug**. Do not enable taint together with these extensions (the test suite disables both).

Taint is a detection tool for development use and is not designed for production deployment anyway.

Install
-------

[](#install)

### Install via PECL

[](#install-via-pecl)

Taint is a PECL extension, simply install it by:

```
$ pecl install taint

```

### Compile from source

[](#compile-from-source)

```
$ /path/to/phpize
$ ./configure
$ make

```

### Usage

[](#usage)

When taint is enabled, if you pass a tainted string(which comes from $\_GET, $\_POST or $\_COOKIE) to some dangerous functions, taint will warn you about that.

```