DEV Community: Tanya

How do you regression-test a ReDoS fix without hanging CI?

Tanya — Sat, 15 Aug 2026 06:22:21 +0000

A known-bad regex is useful evidence, but putting it directly in the test process can hang the runner before the timeout assertion fires.

The boundary I am using:

run each adversarial case in a fresh worker thread or child process
let the parent own a hard timeout and terminate the child
keep semantic-parity fixtures separate from timing guards
require the safer replacement to pass both suites
record the timeout class and bounded elapsed time as evidence

Browser workers have the same trap: startup time should not consume the execution budget, and output limits matter alongside time limits.

Disclosure: I maintain MonoTools. I recently tightened its browser-local Regex Tester around a 300 ms post-startup Worker budget, named groups, replacement previews, and regression cases:
try the bounded tester

What does your team treat as a deterministic CI failure receipt for ReDoS: an exit code, a timeout class, an elapsed-time range, or something else?

CHIPS Won't Restore a Third-Party Chat Session by Itself

Tanya — Sun, 09 Aug 2026 16:42:01 +0000

A partitioned cookie solves one narrow problem: it lets an embedded origin keep a separate cookie jar for each top-level site. That can help an iframe chat widget remember a handle, but it does not reconstruct a conversation by itself.

Imagine chat.example embedded on shop-a.com and shop-b.com. With CHIPS, the browser keys a Partitioned cookie by both the embedded site and the top-level site. The cookie available on shop-a is not the cookie available on shop-b. That reduces cross-site tracking, but it also means CHIPS is not a shared identity system. The distinction matters when debugging a session that seems to disappear.

What still has to exist

A reliable restore flow needs three pieces outside the browser policy:

An opaque conversation handle. Do not put the transcript, email address, or customer record in the cookie.
A server-side mapping from that handle to the conversation the user is allowed to resume.
A fallback when storage is unavailable, such as an explicit sign-in or a first-party continuation flow.

A typical candidate looks like this:

Set-Cookie: __Host-chat=opaque-id; Path=/; Secure; HttpOnly; SameSite=None; Partitioned

Partitioned requires Secure. A cross-site iframe normally also needs SameSite=None. The __Host- prefix keeps the cookie host-bound by forbidding Domain and requiring Path=/. HttpOnly is appropriate when only the server needs the handle.

None of those attributes prove that the browser accepted the cookie, retained it, or will send it in the context you care about.

Test behavior, not API presence

Checking that localStorage, IndexedDB, or document.cookie exists is not enough. Privacy modes, partitioning, permissions, sandbox flags, and browser policy can still make reads or writes fail.

Run a short-lived write/read/delete probe inside the real iframe. Record which operation failed and clean up every temporary value. For cookies, test a disposable candidate and treat the result as evidence for that browser and embedding context, not a universal guarantee.

I maintain MonoTools. Its Storage Probe checks localStorage, sessionStorage, IndexedDB, and a short-lived Partitioned cookie candidate locally. It does not request Storage Access permission or claim that a passing probe guarantees durable identity.

CHIPS is a browser storage boundary. Session restoration is still an application protocol.

What to Remove from Logs Before Sharing Them

Tanya — Fri, 07 Aug 2026 12:50:15 +0000

A useful debug log can also be a credential bundle.

Authorization headers, session cookies, database URLs, webhook endpoints, API keys, and complete environment-variable dumps often appear beside the error you actually need help with. Removing lines named password is not enough: many tokens have provider-specific prefixes, while others are just high-entropy strings near an innocent-looking field name.

Keep the original private

Do not redact the only copy. Preserve the original inside the system where it was collected, then make a separate sharing copy.

Before posting that copy to an issue tracker, chat, documentation page, or AI assistant, check at least:

Authorization, Cookie, and Set-Cookie headers.
Database and cache URLs containing usernames or passwords.
AWS, GitHub, Google, Stripe, Slack, and similar provider credentials.
Private-key blocks and webhook URLs.
Environment assignments containing SECRET, TOKEN, PASSWORD, or API_KEY.
Long random-looking values that may be session IDs or custom tokens.

Exact provider patterns are high-signal. Generic assignments and entropy checks need more judgement because hashes, fixtures, and public identifiers can look similar to secrets.

Preserve the debugging structure

Replace the value, not the surrounding evidence. Keep timestamps, severity, request paths, field names, line numbers, and stack frames when they are safe. Use a consistent marker such as [REDACTED] so repeated values remain easy to trace without exposing them.

Then scan the redacted copy again. The second pass catches credentials repeated in a later request, serialized object, exception message, or copied shell command.

Read the result before sharing it. A scanner can miss an internal token format, and it can flag a harmless random value. Heuristics reduce risk; they do not replace repository scanning, DLP, or a handling policy.

Rotate what already crossed the boundary

Redaction only protects the next copy. If a real credential was already pasted into a ticket, chat, public repository, or external service, assume it may have been read.

Revoke or rotate it, review the relevant provider logs, remove it from public history where possible, and replace the literal with a secret-manager reference. Deleting the message is cleanup, not proof that the credential remained private.

I maintain MonoTools. Its Secret Scanner runs this pre-flight in the current browser tab and creates a redacted copy plus a review report:

https://monoware.app/guides/remove-secrets-from-logs?utm_source=devto&utm_medium=content&utm_campaign=secret_redaction_guide

The scanner is deliberately heuristic. A clean result means “no obvious match was found,” not “this log is safe to publish.”

How to Repair Almost-JSON Without Guessing

Tanya — Sun, 02 Aug 2026 11:51:02 +0000

AI responses, logs, and configuration snippets often look like JSON without
being valid JSON.

Typical examples contain:

Markdown fences around the payload.
Comments.
Single-quoted strings.
Trailing commas.
Bare object keys.
Python literals such as True, False, and None.

The tempting fix is a chain of regular expressions. That works until a string
contains punctuation that looks like syntax. A safer repair workflow is narrow,
explainable, and followed by a real parse.

Keep the original

Do not edit the only copy. Preserve the raw response or log fragment before
changing anything.

If the source includes prose or Markdown, first isolate the candidate JSON
block. A repair tool should not guess which paragraph was intended to be data.

For example:

Here is the result:

```json
{
  status: 'ok',
  retry: False,
  items: [1, 2, 3,],
}
```

The data block is repairable. The surrounding sentence is not part of the
document.

Apply known transformations

Use a deterministic sequence and record every change:

Remove supported comments without touching comment-like text inside strings.
Normalize True, False, and None.
Quote bare object keys.
Replace single quotes only when the structure is unambiguous.
Remove trailing commas.
Parse the result with a strict JSON parser.

These are bounded scans, not blind replacements. Each rule skips quoted
strings. Single-quoted bodies are decoded and then serialized again, so escaped
apostrophes, bare double quotes, and // inside URLs are not treated as syntax.

The example can become:

{
  "status": "ok",
  "retry": false,
  "items": [1, 2, 3]
}

If two interpretations are possible, stop. A visible parse error is safer than
a confident but invented repair.

Validate meaning after syntax

Valid JSON can still be wrong.

An AI response may omit a field, turn a number into a string, or stop halfway
through an array. A log fragment may contain only one nested object from a
larger payload.

After the strict parse:

Compare the result with a known-good example.
Check important value types.
Use a JSON Schema for API payloads.
Use a tree diff for configuration changes.
Keep the repair report with the result during review.

Syntax repair answers "can this be parsed?" It does not answer "is this the
right data?"

Keep production payloads local

Broken JSON often comes from places that contain customer data, internal IDs,
or credentials. Sending it to a formatter creates another copy outside the
system you are debugging.

MonoTools JSON Repair runs in the current browser tab and shows the repair
rules it applied:

https://monoware.app/guides/repair-broken-json-safely?utm_source=devto&utm_medium=content&utm_campaign=json_repair_guide

The guide also links the next checks: strict formatting, JSON Tree Diff, and
JSON Schema.

Disclosure: MonoTools is my project. The repair tool intentionally leaves
ambiguous input unresolved instead of pretending every invalid document has one
obvious answer.

How to Remove EXIF and GPS Metadata Before Sharing a Photo

Tanya — Fri, 31 Jul 2026 06:04:44 +0000

A JPEG can contain GPS coordinates, capture times, camera and lens details,
editing software, comments, and copyright fields. That may be useful in a
private archive, but risky in a public issue, marketplace listing, or social
post.

Do not assume the upload destination will remove it. Platforms process formats
differently and can change behavior. Create a clean public copy before the file
leaves your control.

Inspect a sharing copy

Keep the original private. On a separate copy, check for GPS data, timestamps,
camera identifiers, and EXIF, XMP, or IPTC fields. The goal is not to damage
your archive; it is to make a public file containing only what the destination
needs.

A practical workflow is:

Inspect the sharing copy locally.
Export a cleaned file.
Inspect that exact output again.
Review what is visible in the pixels.
Rename it clearly before uploading.

The MonoTools EXIF Inspector & Cleaner does this in the current browser tab.
The selected photo is read through browser APIs and is not uploaded to a
processing server.

Understand the format boundary

JPEG stores metadata in APP and COM segments around its compressed image data.
The cleaner can remove EXIF, XMP, Photoshop/IPTC data, comments, and optional
unknown APP containers without recompressing pixels.

PNG cleanup covers EXIF, XMP/text, and modification-time chunks. WebP cleanup
covers EXIF and XMP chunks. All three exports keep their original format and
are scanned again before the metadata check passes.

ICC profiles stay by default because removing them can change color rendering
in managed workflows. If you choose to remove one, compare the cleaned copy
with the original when color accuracy matters.

The tool can also copy or download a versioned JSON policy report. Metadata
checks receive separate source and cleaned-output pass/fail results. Visible
pixels remain a human gate, and raw metadata values are omitted.

Check the pixels too

Metadata removal cannot hide information already visible in a photo. Look for
street signs, faces, badges, vehicle plates, screens, shipping labels, QR
codes, landmarks, and reflections. Cropping, blurring, or replacing the image
may still be necessary.

If the public copy also needs resizing or format conversion, do that after the
privacy review, then inspect the final file again. Compression and metadata
cleanup solve different problems.

I maintain MonoTools and wrote a fuller guide for its browser-local EXIF
Inspector & Cleaner:

https://monoware.app/guides/remove-exif-metadata-before-sharing?utm_source=devto&utm_medium=content&utm_campaign=exif_cleanup_guide

Disclosure: MonoTools is my project.

How to Compress Images in the Browser Without Uploading Them

Tanya — Fri, 31 Jul 2026 05:59:23 +0000

A screenshot can be 4000 pixels wide even when a page renders it at 900
pixels. Lowering the quality slider may help, but the better first question is:

What is the largest size at which this image will actually be displayed?

Resize first

If an image never renders wider than 1200 pixels, shipping a 4000-pixel source
wastes download bytes and browser memory. Resize to the largest useful display
width, preserve the aspect ratio, and do not upscale a smaller source.

For a one-off asset, the whole process can stay in the browser:

Decode the selected file locally.
Scale it to a maximum width.
Draw it to a Canvas.
Export with the browser's WebP, JPEG, or PNG encoder.
Compare dimensions and file size, then inspect the preview.

This is how the MonoTools Image Optimizer works. The selected file remains in
the current tab instead of being sent to an image-processing service.

Choose a format for the content

WebP is a useful default for screenshots and mixed-content images. It supports
transparency and often produces smaller files than JPEG or PNG.

JPEG suits photographs when transparency is unnecessary. Reduce quality
carefully around faces, text overlays, sharp UI edges, and gradients.

PNG remains appropriate for lossless graphics and transparency. A browser's
quality setting does not make PNG behave like lossy JPEG, so moving the slider
may have little effect.

Conversion alone is not optimization. Compare the actual output and view it
near its intended page size. Small text, one-pixel borders, shadows, and logo
edges tend to reveal damage first.

Know the limits

Local processing avoids an upload, but decoded images can consume far more
memory than their compressed files. Very large sources may slow the tab or
make Canvas export fail. Reduce the target width or process one image at a
time when that happens.

Browser encoders can also produce slightly different output. This workflow is
good for individual assets and visual review; a versioned build dependency is
better for large batches or reproducible production output.

Use srcset or picture when a page needs several responsive sizes. Also
inspect GPS, camera, or timestamp metadata separately: resizing an image does
not guarantee that private metadata is removed.

I maintain MonoTools and wrote a fuller guide for its browser-local Image
Optimizer:

https://monoware.app/guides/compress-images-locally?utm_source=devto&utm_medium=content&utm_campaign=local_image_compression

Disclosure: MonoTools is my project.

How to Inspect a JWT Without Uploading a Production Token

Tanya — Thu, 30 Jul 2026 16:08:15 +0000

A JSON Web Token often looks like opaque security data, but its header and
payload are normally readable Base64URL segments. That makes local inspection
straightforward. It also creates two common mistakes:

Uploading a live bearer token to an unknown server-side decoder.
Treating decoded claims as proof that the token is authentic.

This workflow separates three different jobs:

Inspecting the token structure.
Checking claims such as issuer, audience and expiration.
Verifying that a trusted issuer signed the token.

The first two can be done locally in a browser tab. The third requires the
expected algorithm and trusted key material.

1. Treat the JWT as a credential

A JWT may be readable, but it can still grant access to an API. If it is a
bearer token, anyone who receives the original compact token may be able to use
it until it expires or is revoked.

Before debugging, decide what kind of token you are handling:

A fake or test token is usually safe to paste into examples.
A staging token may still expose internal systems.
A production token should not be copied into public tools, tickets or chat.

If a production token has already crossed an untrusted boundary, redaction is
not enough. Rotate or revoke it and treat the event as a credential exposure.

2. Split the compact token

A typical JWT has three dot-separated segments:

header.payload.signature

The header and payload are Base64URL-encoded JSON. They are not encrypted by
default. That means you can decode the first two segments locally and read the
claims without sending the compact token to a server.

The header usually includes fields such as:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "example-key-id"
}

The payload may include registered claims:

{
  "iss": "https://issuer.example",
  "aud": "api.example",
  "sub": "user_123",
  "exp": 1764211200,
  "nbf": 1764207600,
  "iat": 1764207600,
  "scope": "read:profile"
}

Do not paste a real token into an article, issue or support ticket. Use a
synthetic example or share only the claim values needed to explain the failure.

3. Check the claims that commonly fail

Most authentication debugging starts with a small set of fields.

`iss`

The issuer must match the identity provider or token service expected by the
API. A common failure is using a token from the right environment but the wrong
issuer configuration.

`aud`

The audience should identify the API or client that the token was issued for.
If the token was minted for a different API, the claims may look correct while
the request still fails authorization.

`exp`, `nbf` and `iat`

JWT numeric date fields are seconds since the Unix epoch. Many bugs come from
mixing seconds and milliseconds.

Check:

Is exp already in the past?
Is nbf still in the future?
Does iat make sense for the login or refresh event?
Are the server and client clocks skewed?

Custom roles and scopes

Applications often encode permissions in custom claims such as scope,
roles, permissions or tenant-specific fields. These are useful for
debugging, but they are only trustworthy after signature verification.

4. Decoding is not verification

Anyone can construct a JWT-looking string with a header and payload. A decoder
can tell you what the token claims. It cannot tell you whether the token was
signed by the expected issuer.

Verification needs:

The expected algorithm.
The trusted signing secret or public key.
Issuer and audience checks.
Rejection of unexpected algorithms.
Current time validation for exp and nbf.

For HS256 development tokens, the verifier needs the shared secret. For RS256,
ES256 or production identity providers, the backend normally verifies against a
published JWKS or a configured public key.

Do not trust the alg value from the token by itself. Your verification code
should enforce the algorithm that the application expects.

5. Build a share-safe diagnostic

The useful output of JWT debugging is usually not the original token. It is a
small set of facts:

Token structure: 3 JWT segments
Header alg: RS256
Header kid: example-key-id
Issuer: https://issuer.example
Audience: api.example
Subject: user_123
exp: 1764211200 / 2025-11-27T00:00:00Z
nbf: 1764207600 / 2025-11-26T23:00:00Z
Verification error: audience mismatch

Before sharing the diagnostic:

Remove the original compact token.
Remove unrelated cookies or authorization headers.
Scan the remaining text for other credentials.
Include the exact verification error and expected issuer or audience.

That gives the next person enough context to debug without receiving a reusable
credential.

6. A local workflow

My preferred workflow is:

Decode the JWT header and payload locally.
Convert exp, nbf and iat to readable dates.
Compare iss and aud with the API configuration.
Verify the signature in backend code or a local lab with trusted key material.
Redact the original token before opening a ticket or asking for help.

I maintain MonoTools, including a browser-local JWT decoder and the longer
canonical guide for this workflow:

https://monoware.app/guides/inspect-jwt-without-uploading?utm_source=devto&utm_medium=content&utm_campaign=jwt_local_guide

Disclosure: MonoTools is my project. The guide and decoder are useful for local
inspection, but signature verification still belongs in trusted verification
code with the expected key material.