Back to Security at Intentia

Intentia Application Security Review

Public edition

Review carried out: 9 October 2026 · Remediation re-tested and status verified: 13 October 2026

1. Executive summary

In October 2026 the Intentia application was reviewed for security weaknesses before any independent testing. The review looked at how the application controls who can see and change information, how it handles the data people enter, and how its signing and payment steps are protected.

The review identified a number of issues of varying importance. The issues assessed as attack paths – ways in which someone outside the organisation could have reached information that was not theirs – were fixed and re-tested against a running copy of the application. Following that verification, no exploitable external attack path was identified in the application components tested.

This is a scope-bound result. It does not mean every risk has been removed: some lower-priority hardening, operational and data-protection items recorded by the review remain open, have been accepted by the business, or have been deferred to later work, and several areas were outside the review’s scope (see section 6).

2. What Intentia does

Intentia helps families document gifts and loans towards a home deposit and produces the related documents, including a Memorandum of Intention, which the people involved sign electronically. To do this it handles personal information, financial information about the gift or loan, payment information and signed documents. Intentia is a service provided by IDR Law Limited.

3. Security areas examined

• Sign-in and sessions – how passwords are stored, limits on repeated sign-in attempts, and whether altered, forged or expired session tokens are rejected.
• Ownership of submissions and documents – whether one user, or an anonymous visitor, can read or change another person’s questionnaire answers or documents, including questionnaires started before an account was created.
• Payment-related information – whether payment details can be looked up by anyone other than the signed-in owner, and whether a matter can be marked as paid without a genuine notification from the payment provider.
• Role permissions – whether ordinary users or anonymous visitors can use administrative or partner functions.
• Input handling and injection – how the application deals with unexpected or malicious input, including common database-injection and script-injection techniques, and how entered text is placed into generated documents.
• Document and signing workflow – signer codes, limits on repeated incorrect attempts, preventing a document being signed twice, preventing changes after signing, and checks on where people are sent back to after identity verification.
• Outbound messages – limits on how often a Memorandum of Intention can be shared by email.
• Configuration, dependencies and error handling – whether errors reveal technical detail, whether third-party software components had known vulnerabilities, and how sensitive configuration is managed.

4. How the review was conducted

The review was carried out internally with the help of an AI assistant and combined three methods:

• Source-code analysis of the server-side application and its web components.
• Automated checks, including static code scanning, scanning for exposed credentials and checking third-party components against published vulnerability lists.
• Safe local testing of the application’s back-end service, run on an isolated computer against a separate database containing only made-up test data. No real client information was used, and the live service was not tested.

Not every control was tested in the running application. Access between ordinary users and anonymous visitors, token handling, sign-in limits, injection attempts and most of the fixes described below were tested at runtime; the third-party component updates were confirmed by re-running the vulnerability scan. Some other controls – for example certain lockout behaviour, settings that apply only in the live environment, and permissions as seen from administrator and partner accounts – were assessed by reviewing the code rather than by live testing.

5. Review outcome

Within the documented scope, the identified application-layer attack paths were addressed and re-tested, in the running application or, for component updates, by re-scanning. These included protecting questionnaires started before an account is created so that only the person who started them can open them, requiring sign-in and ownership before payment details are returned, shortening how long a session token remains valid, updating third-party components with known vulnerabilities, and restricting where identity-verification links can send people.

Controls that were already in place and held up when tested included refusing ordinary users and anonymous visitors access to administrative and partner functions, rejecting tampered or forged session tokens, limiting repeated sign-in attempts, and refusing access to other users’ owned submissions.

The review also recorded items that are not, in its assessment, exploitable external attack paths within the tested scope but still matter. Some have been addressed; others remain open, have been accepted by the business, or have been carried forward to infrastructure and future work. These include improvements to how certain sensitive configuration is managed, additional browser-side protections, and reducing personal information written to internal logs. We do not publish a detailed list of these items, but clients and partners with a genuine assurance need can ask us for more information (see section 7).

6. Scope and limitations

The following were outside the scope of this review and were not tested:

• production hosting, servers and their configuration;
• the network edge, including firewalls and the encryption of connections at the edge;
• behaviour that only occurs in the live environment, beyond what could be checked in code;
• real-world attacks that chain several weaknesses together;
• independent penetration testing or external certification;
• the Intentia mobile app;
• ongoing or continuous security monitoring.

The local testing focused on the application’s back-end service. Some areas were reviewed only partly, or not exercised at runtime, including the browser-facing parts of the website, automated web-application scanning, the password-reset process provided by a third-party sign-in service, and live testing from administrator and partner accounts. The results describe the application as it stood when reviewed; later changes are not covered unless re-tested.

No security review can guarantee that a system is free of vulnerabilities.

7. Questions or concerns

If you have a question about this review, need further assurance information for your organisation, or believe you have found a security problem in Intentia, please contact us.