XSS in Outlook Web Add-ins: Risks, Tradeoffs, and Fixes

const subjectEl = document.getElementById("subject");
subjectEl.textContent = item.subject || "";
```text

For larger chunks of content:

```javascript
const previewEl = document.getElementById("preview");
previewEl.textContent = emailBody;

import DOMPurify from "dompurify";

const clean = DOMPurify.sanitize(emailHtml, {
  USE_PROFILES: { html: true }
});

document.getElementById("content").innerHTML = clean;
```text

#### Pros

- Preserves formatting
- Better UX for email-heavy workflows
- More flexible for annotation and review features

#### Cons

- Easy to get wrong
- Sanitizer config drift becomes a security problem
- Developers often reintroduce risk with post-sanitize DOM manipulation
- Rich HTML still creates attack surface through allowed tags and attributes

This approach is fine, but only if you treat sanitization as a security control, not a formatting helper.

A common failure looks like this:

```javascript
const clean = DOMPurify.sanitize(emailHtml);
container.innerHTML = clean;

// later
container.querySelectorAll("a").forEach(a => {
  a.setAttribute("target", "_blank");
});

container.innerHTML = item.subject;
```text

#### Pros

- Fast to write
- Flexible for templating

#### Cons

- Dangerous with untrusted data
- Easy footgun
- Usually unnecessary

My opinion: ban it by default.

### `textContent`

```javascript
container.textContent = item.subject;

const li = document.createElement("li");
const strong = document.createElement("strong");
strong.textContent = senderName;

li.appendChild(strong);
li.appendChild(document.createTextNode(`: ${subject}`));
list.appendChild(li);
```text

#### Pros

- Safer than string-built HTML
- Explicit structure
- Good for component rendering without a framework

#### Cons

- Verbose
- Developers sometimes fall back to string concatenation out of frustration

For small add-ins, this pattern ages better than people expect.

## Framework auto-escaping: good, but not magic

If your Outlook add-in uses React, Vue, Angular, or similar, you get some protection from default escaping.

React example:

That is much safer than manual string rendering.

But the usual escape hatches are still dangerous.

#### Pros of framework templating

- Safer defaults
- Less accidental DOM XSS
- Easier to standardize patterns across the team

#### Cons

- Dangerous escape hatches still exist
- Third-party UI components may inject raw HTML
- Developers often trust server-rendered HTML too much

If you use a framework, create a single reviewed component for sanitized HTML rendering and make everything else text-only by default.

## CSP in Outlook add-ins: useful, but constrained

Content Security Policy still matters for Outlook web add-ins, especially when you want a backstop against inline script execution and surprise script sources.

A good CSP can reduce exploitability when someone slips unsafe rendering into the codebase.

Example:

#### Pros

- Strong defense-in-depth
- Limits script execution paths
- Helps catch bad assumptions during testing
- Useful for hardening add-in pages and task panes

#### Cons

- Outlook add-in hosting requirements can limit how strict you can be
- Legacy libraries may force weaker policies
- Inline event handlers and ad-hoc scripts become painful to maintain

You should still do it. Just expect a little friction.

For CSP implementation details and rollout patterns, [csp-guide.com](https://csp-guide.com) is useful. For Office add-in hosting behavior and platform requirements, stick to the official Microsoft documentation.

## Comparing sanitization strategies

### Centralized sanitizer wrapper

```javascript
import DOMPurify from "dompurify";

export function renderTrustedHtml(el, dirtyHtml) {
  const clean = DOMPurify.sanitize(dirtyHtml, {
    ALLOWED_TAGS: ["b", "i", "em", "strong", "p", "br", "ul", "ol", "li", "a"],
    ALLOWED_ATTR: ["href"],
    ALLOW_DATA_ATTR: false
  });

  el.innerHTML = clean;
}

export function setText(el, value) {
  el.textContent = value ?? "";
}

export function setSafeHtml(el, html) {
  const clean = DOMPurify.sanitize(html, {
    USE_PROFILES: { html: true }
  });
  el.innerHTML = clean;
}
```text

Then make direct DOM sinks a code review violation.

## Best option by use case

### Showing subjects, names, metadata

Use plain text.

**Best choice:** `textContent`

### Showing snippets or previews

Use plain text unless formatting is a hard requirement.

**Best choice:** plain text first, sanitized HTML only if justified

### Rendering full email body content

Use a strict sanitizer and isolate the feature mentally as high risk.

**Best choice:** centralized sanitization plus CSP

### Building interactive add-in UIs

Use a framework with auto-escaping, but lock down raw HTML escape hatches.

**Best choice:** framework templating plus reviewed safe HTML component

## The practical takeaway

The real comparison is not “can Outlook add-ins get XSS?” Of course they can.

The useful comparison is between teams that treat mailbox content as hostile and teams that treat it as business data. The first group usually ends up with boring, effective defenses. The second group ends up debugging why a calendar description executed script in a trusted enterprise tool.

For Outlook web add-ins, my bias is simple:

- text by default
- sanitized HTML rarely
- CSP always if you can
- zero trust for mailbox content

That approach is not glamorous, but it keeps your add-in from becoming the easiest XSS target in the mail client.