Six flags are worth a look after strict: noUncheckedIndexedAccess, exactOptionalPropertyTypes, noImplicitOverride, noPropertyAccessFromIndexSignature, noImplicitReturns and noFallthroughCasesInSwitch. None are in strict, so you enable each yourself. The first one is the most useful for code that reads headers, query strings and environment variables, because it forces you to handle a missing value.
The six flags in one table
All descriptions below come from the TypeScript tsconfig reference.
| Flag | What it does | Adoption cost |
|---|---|---|
| noUncheckedIndexedAccess | Adds undefined to values read through index signatures | Medium to high |
| exactOptionalPropertyTypes | An optional property means absent or the declared type, not "possibly undefined" | Medium |
| noImplicitOverride | Requires the override keyword when overriding a base class method | Low |
| noPropertyAccessFromIndexSignature | Forces bracket syntax for index signature properties | Low to medium |
| noImplicitReturns | Checks all code paths return a value | Low |
| noFallthroughCasesInSwitch | Reports non-empty switch cases without break, return or throw | Low |
Why the first one matters most
With an index signature like a map of strings, TypeScript normally types a lookup as a plain string. With noUncheckedIndexedAccess on, env.NODE_ENV becomes string | undefined, per the reference. That is the honest type: the key might not be there. Headers, query parameters and cookies behave the same way, so the compiler now forces you to decide what happens when a value is missing.
That decision is where security bugs live. A missing role header that defaults to an empty string and then passes an includes check is the kind of thing this flag surfaces.
The quieter ones
noFallthroughCasesInSwitch is cheap and sometimes catches an authorization switch where one case falls into the next. The reference gives the plain rule: any non-empty case needs break, return or throw.
noImplicitReturns flags a function with a path that returns nothing, which matters in a permission check that is supposed to return true or false on every path.
noPropertyAccessFromIndexSignature makes settings.username an error and requires settings["username"]. The reference explains this signals that the property is not explicitly declared. It is a readability aid more than a safeguard, so adopt it last.
exactOptionalPropertyTypes is the one to be careful with. It can produce errors in code that passes objects between libraries, because assigning undefined to an optional property becomes an error. Try it in a branch before committing to it.
A sensible order
- Turn on
noImplicitReturnsandnoFallthroughCasesInSwitch. Expect few errors. - Turn on
noImplicitOverrideif you use classes. - Turn on
noUncheckedIndexedAccessand fix each error with a real check, not a non-null assertion. An exclamation mark assertion silences the compiler and brings the bug back. - Evaluate
exactOptionalPropertyTypesandnoPropertyAccessFromIndexSignaturelast.
What none of them do
These flags make the compiler stricter about shapes. They do not validate data at run time and they do not find injection. See Is TypeScript strict mode a security setting for the first layer and use scanning for the rest.
Try it yourself
Open the pull request gate demo and see how a failed check blocks a merge. A compiler check in CI works the same way.
Click through it at your own pace, or open it full screen.
Safeguard policies and gates can block a pull request on dependency findings, so type errors and vulnerable packages fail in the same place. A free scan shows what your lockfile contains today.
Quick check
Is noUncheckedIndexedAccess part of strict?
No. You enable it separately.
Should I use a non-null assertion to clear the new errors?
Avoid it. It silences the compiler without handling the missing value. Add a real check instead.
Sources
Last reviewed: 19 October 2026.
