An explicitly allowed origin
The validator compares the URL’s full origin with the configuration: scheme, host and normalized port. A loopback address is accepted only when its origin is explicitly configured.
Internal review · TypeScript · 8 November 2026
An allowed URL needs an allowed origin.
A review of an INOBIC application’s URL validator revealed an overly broad rule. We reproduced the issue in tests, fixed the component and ran the same checks again.
Fix validated locally. The product’s deployment is outside this study’s scope.
What we reviewed
The component receives a return URL and should restrict its destination to origins configured by the application. Testing covered this validator and its local tests, using synthetic configuration. No external service calls or attempts against a real account were needed.
The product and its internal paths are anonymized. The domains below are synthetic; raw logs and operational configuration remain private.
The issue: checking only the hostname
The original check compared hostnames without requiring the full origin to match. It also implicitly allowed loopback addresses. An origin distinguishes the scheme, hostname and port: changing the port can point to another service.
Allowed origin: https://app.example.test
Allowed return: https://app.example.test/account
Different origin: https://app.example.test:8443/accountThe demonstrated defect is overly permissive validation. These tests do not establish account takeover, data leakage or exploitation of the complete production flow. Impact depends on the destinations that are actually reachable and how the application uses them.
The fix
A restricted, validated format
Only HTTP or HTTPS URLs without embedded usernames or passwords are accepted. Invalid configuration entries are ignored, and destinations outside the allowlist are rejected.
The same tests, before and after
Before the fix
4 passed and 7 failed out of 11 regression tests.
After the fix
All 11 passed, using the same test selection and configuration.
Additional checks
All 61 module tests and 4 related route tests passed. TypeScript checking and the API build also passed.
The checks cover ports, schemes, credentials embedded in URLs and loopback origins. They do not replace integration testing with production configuration.
Published files and limitations
The validation record contains the results and hashes of the component before and after the fix. The downloadable example illustrates the origin rule with synthetic domains. It contains one standalone test; it does not reproduce the application’s private implementation or its complete flow.
node --test origin-policy.test.mjsThe fix was validated in the local environment. Operational configuration, the external flow and deployment need separate verification before release.
Apply this approach to your code
An explicit rule, a reproducible defect, a focused change and checks of expected behaviour: that is what makes a review useful to the team maintaining the product.