Many security fixes work by changing a default: a stricter limit, a closed-by-default option, a check that used to be optional. To spot one, read the changelog for words like default, now, and no longer, diff the configuration code, and test the behavior your app relied on. Then set the old value explicitly only if you can justify it.
Why defaults are the quiet breaking change
If a library was vulnerable because a risky option was on by default, the safe fix is to turn it off. Applications that never set the option now behave differently, with no code change on their side. Nothing fails to compile, nothing logs a warning, and the unit tests may not notice.
Semantic Versioning defines a bug fix as an internal change that fixes incorrect behavior, so a default change meant to close a hole can legitimately ship in a patch release. The version number will not warn you. The release notes might.
Where to look
- The changelog. The Keep a Changelog convention groups entries under headings such as Changed, Removed, Fixed and Security. Read the Changed and Security sections first. Search the page for the words default, now, no longer, stricter, disabled and enabled.
- The advisory. It often says how the fix works. If it says "the option X is now off by default", you have your answer.
- The code diff. Compare the two versions and search for the configuration object. Changed default values are easy to find in a diff, even when they are missing from the notes. Our post on reading the diff between two package versions shows how.
- The documentation for the new version. Option tables list defaults. Compare them with the old version's table.
Test the behavior, not the setting
Once you know a default changed, write down what your application used to get for free and test for it.
| Typical default change | What may break | What to test |
|---|---|---|
| A size or depth limit is now enforced | Large legitimate inputs are rejected | Upload or send your largest real payload |
| Remote content loading is off | Features that fetch external resources stop working | Run every flow that references outside URLs |
| Stricter certificate or hostname checks | Internal services with self signed certificates fail | Call each internal endpoint from staging |
| Cookie or header attributes tightened | Embedded or cross site flows stop working | Test login and embedded widgets in the browsers you support |
| Unknown fields now rejected | Older clients sending extra fields get errors | Replay requests from your oldest client versions |
Decide: adopt the new default or restore the old one
Adopt the new default whenever you can. It is the fix. If something legitimate breaks, change the producer of the input, or widen the specific limit rather than turning the protection off.
If you must restore the old value, treat it like an exception. Set the option explicitly in code, add a comment with the reason and a review date, and record it in your exception register. An explicit old value is also easier to find in a later audit than an implicit one.
Make future changes easier to see
Set important security options explicitly in your own configuration, even when they match the default. Then a future change to the library default cannot silently change your behavior, and the setting is visible in code review. Add a test that fails if the effective value differs from what you expect.
Safeguard's policies and gates can hold pull requests that touch security relevant dependencies for review, and dependency scanning shows where each library is used. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through a finding from discovery to fix and note where a reviewer would pause to check what the fix changes.
Quick check
How do I find changed defaults when the notes do not mention them?
Diff the two versions and search for the configuration code, then compare the option tables in the documentation for each version.
Should I always set the old value back?
No. The new default is usually the fix. Restore the old value only with a stated reason, a review date and a record in your exception register.
Sources
Last reviewed: 19 October 2026.
