` change how content is *displayed*; they do not change how it is *parsed*. Markup inside them is still markup, and still removed. Escape there too — in practice, escape there especially, because that is where payloads normally live.
**Wrong:**
```html
GET /search?q= HTTP/1.1
Host: example.com
```
Stored as `GET /search?q= HTTP/1.1` — the payload is gone from the request you were documenting.
**Right:**
```html
GET /search?q=<script>alert(1)</script> HTTP/1.1
Host: example.com
```
The same applies to inline code:
```html
The parameter accepts <svg onload=alert(1)> unfiltered.
```
`` is the one place where line breaks and indentation are preserved exactly as you send them. Everywhere else, whitespace between tags is insignificant.
#### 2.5 Escaping is safe to apply, and safe to apply twice
Escaped content is stable. Sending `<script>` stores `<script>`; it is never double-escaped into `<script>`, and it survives a round trip through the web application's editor unchanged. You can escape confidently without worrying about accumulating entities on each save.
If you genuinely want the reader to see the *entity* `<` rather than a `<` character, escape the ampersand yourself and send `<`.
Numeric character references work as well as named ones: `<` and `<` are both accepted alternatives to `<`.
#### 2.6 Never rely on a bare `<`
A bare `<` in your text is a coin toss. Whether it is escaped for you or eaten depends on whether the parser can find something tag-shaped after it:
| What you send | What is stored |
| ---------------------------- | ---------------------------------------------------------- |
| `1 < 2
` | `1 < 2
` — escaped for you |
| `Tom & Jerry < 5 > 3
` | `Tom & Jerry 3
` — `< 5 >` read as a tag and deleted |
| `a > b
` | `a > b
` — a stray `>` is escaped for you |
Do not depend on the forgiving cases. Escape every `<` and `>` in literal text and the outcome is never in question.
#### 2.7 Building the request body safely
Escape the text, interpolate it into your markup, then let your JSON library serialise the result. **HTML escaping and JSON escaping are separate layers** — your HTTP client handles the JSON layer; only you can handle the HTML layer.
**JavaScript / TypeScript**
```js
const escapeHtml = (s) =>
s.replace(/&/g, '&')
.replace(//g, '>')
.replace(/"/g, '"');
const payload = ``;
const richtext = `The search parameter reflected ${escapeHtml(payload)} without encoding.
`;
await fetch('https://your-tenant.attackforge.com/api/ss/vulnerability', {
method: 'POST',
headers: { 'X-SSAPI-KEY': apiKey, 'Content-Type': 'application/json' },
body: JSON.stringify({ steps_to_reproduce: richtext, /* … */ }),
});
```
**Python**
```python
import html, requests
payload = ""
richtext = f"The search parameter reflected {html.escape(payload)} without encoding.
"
requests.post(
"https://your-tenant.attackforge.com/api/ss/vulnerability",
headers={"X-SSAPI-KEY": api_key},
json={"steps_to_reproduce": richtext},
)
```
`html.escape` handles `&`, `<`, `>` and quotes in the correct order.
**Bash with `jq`**
```bash
payload=''
escaped=$(printf '%s' "$payload" | sed -e 's/&/\&/g' -e 's//\>/g')
richtext="The search parameter reflected ${escaped} without encoding.
"
jq -n --arg r "$richtext" '{steps_to_reproduce: $r}' \
| curl -sS -X POST "https://your-tenant.attackforge.com/api/ss/vulnerability" \
-H "X-SSAPI-KEY: $API_KEY" -H 'Content-Type: application/json' -d @-
```
Substituting `&` first is what makes the `sed` chain correct; reordering it produces `<`.
#### 2.8 What not to do instead
None of the following preserve your content. Escape with HTML entities — there is no alternative mechanism:
* **``** — an XML construct with no meaning in HTML. The payload inside it is still removed, and the `` markers are left on screen around the gap.
* **Backslash escaping** (`\`) — the backslashes are displayed literally and the tag is still removed.
* **Base64 or URL encoding the payload** — the reader sees an encoded blob rather than the payload.
* **Zero-width or lookalike characters** inserted to break up the tag — they corrupt the payload for anyone who copies it out to retest.
* **Wrapping the payload in `` or `` without escaping** — as shown in section 2.4, this does not help.
***
### 3. Supported tags
Only the tags in this table are stored. Everything else is removed.
| Tag | Purpose | Attributes | Example |
| -------------------- | --------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| `` `` `` | Headings | None | `Steps to Reproduce
` |
| `
` | Paragraph | None | `
Body text.
` |
| `` | Code block | None | `const num = 100;
` |
| `` | Block quote | None | `Observed 2026-05-01.
` |
| `` | Numbered list | None | `- first
- second
` |
| `` | Bulleted list | None | `- one
- two
` |
| `- ` | List item | None; valid only inside `
` or `` | `- item text
` |
| `` | Table | `style` (required) — see section 5 | see section 5 |
| `` | Table body | None; valid only inside `` | `…` |
| `` | Table row | `style` (optional, `height` only) | ` … ` |
| `` | Table cell | `style` (required) — see section 5 | ` cell
` | Empty table cell only | None; valid only as `
` inside a `` | `
` |
| `` | Bold | None | `bold` |
| `` | Italic | None | `italic` |
| `` | Underline | None | `underline` |
| `` | Strikethrough | None | `struck` |
| `` | Highlight | `data-highlight` (required): `orange`, `red`, `green`, `blue` or `violet` | `Critical` |
| `` | Inline code | `class` (required): `inline-code-container` | `q` |
| `` | Hyperlink | `href` (http/https), `rel="noopener noreferrer"`, `target="_blank"` — all three | `link` |
Use `` and `` rather than `` and ``. Bare `` and bare `` are not supported — both require their attribute.
***
### 4. Structure rules
**Send minified HTML.** No newlines, tabs or indentation between tags. Whitespace *within* visible text is preserved, and whitespace inside `` is preserved exactly; everywhere else it is insignificant, and pretty-printed markup will not survive as you formatted it.
**There is no line-break tag.** Separate lines are separate `` elements. `
` has exactly one valid use: representing an empty table cell as `
`.
**Block tags do not nest.** ``, ``, ``, `
`, `
`, ``, ``, `` and `` are block-level and must not contain one another, except that ``/`` contain `- `, and table cells may contain `
` and lists.
**Lists do not nest.** `
` and `` may contain only `- ` elements, and an `
- ` may not contain another list.
**Inline tag placement:**
| Container | Inline tags allowed |
| -------------------- | ------------------------ |
| `
` | All |
| `
- ` | All |
| `
` `` `` | None — plain text only |
| `` | None — plain text only |
| `` | `` highlights only |
**Emphasis combines; the others do not.** ``, ``, `` and `` may be nested within one another. Highlight spans, `` and `` may not be combined with emphasis tags or with each other — their content cannot be styled.
***
### 5. Tables
Structure is fixed and must nest in exactly this order:
```
→ → →
```
There are no header cells. `` and `` are not supported — a header row is an ordinary ` ` of `` elements whose content you make bold. If you send ``/`` anyway, the tags are stripped and the header text collapses out of the table structure.
#### Widths
`` and `` each require a `style` attribute carrying a single width property, and a table must use one of two modes consistently:
**Default mode — no explicit widths.** Every ` ` uses `style="min-width:100px;"`, and `` uses `style="min-width:Xpx;"` where X is the sum of the `min-width` values of the cells in one row.
**Explicit mode — you specify a width for any column.** The whole table converts to `width`. Every `` uses `style="width:Ypx;"` — your value for that column, or `100px` for columns you did not specify — and `` uses `style="width:Xpx;"` where X is the sum of the row's cell widths. No cell keeps `min-width`.
Rules that apply to both modes:
* `min-width` and `width` are the only permitted style properties, never both on the same element.
* A single table must not mix `min-width` cells with `width` cells.
* Values must be in pixels. Percentages and other units are rejected.
* **Use two or more digits.** `100px` and `10px` are accepted; `5px` is rejected and the whole style attribute is dropped.
* Omitting the `style` attribute is invalid.
#### Rows
`` accepts an optional `style` carrying only a `height` in pixels, e.g. ` `. Include it only when you want a specific row height; otherwise omit the attribute entirely. Row height is independent of column widths and works with either mode.
#### Cell contents
A `` may contain one or more `` elements and `
`/`` lists. Cell paragraphs and list items follow the normal inline rules, highlights included.
Not allowed inside a ``: code blocks (``), image tokens, headings, blockquotes, and nested tables.
An empty cell is written as `
`.
#### Example
```html
Field
Detail
Parameter
q
Notes
```
With explicit widths of 250px and 120px, and a third column left unspecified — note that every cell converts to `width`, and the table width is 250 + 120 + 100 = 470:
```html
api.example.com
443
```
***
### 6. Images
There is no `![]()
` tag in rich-text. Images are referenced by a token naming a file that already exists in AttackForge:
```html
{{{login-bypass.png}}}
```
* Three braces on each side, wrapped around the filename.
* The filename must match an uploaded file exactly. Upload the file to the record first, then reference it by name.
* The token must be the only content of its `` — no text, whitespace or other tags beside it. `
See {{{login-bypass.png}}}
` will not render as an image.
* Do not escape anything inside the token; the braces and filename are literal.
* Image tokens are not permitted inside table cells.
***
### 7. What gets removed
#### Deleted entirely, contents and all
| Sent | Result |
| -------------------------------------------------------------- | ------------------------------ |
| `` | Tag and its inner text removed |
| `![]()
`, `