Apache Fineract security hardening

Each hardening control should have a test that a reviewer can run again and get the same result. Start with the controls most likely to fail silently after a configuration change. First, attempt to log in with the default development credentials that the Fineract README lists for the mifos account. The expected result is a rejected login with no session token issued. Second, send a plain HTTP request to the public API address and expect no service to answer, which confirms that HTTPS is the only listener in front of the platform. Third, send API requests with a missing tenant header, an unknown tenant identifier and the identifier of another institution's tenant, using the Fineract-Platform-TenantId header. Each request should return an error, and no response body should contain records belonging to another tenant.

Next, test the network and API boundaries. From a host outside the Fineract network segment, attempt a direct connection to the PostgreSQL port and expect the connection to be refused or dropped at a firewall or security group that you can name in the test record. Then call the API paths your deployment should not expose, including any administrative, health or documentation paths your configuration enables, and record the status code for each. Build this list from your own route inventory, because it depends on which modules and extensions you have deployed. Finally, check logging. Trigger a failed login and a rejected tenant request, then confirm that each event appears in the central log store with a timestamp, source address and user or tenant context. A failure that is never logged cannot be investigated.

Negative tests check what happens when a dependency fails. In a staging environment, make the identity provider unreachable and attempt to log in through the OAuth2 path. The platform should reject the request. It should not fall back to HTTP basic authentication or accept an anonymous session. Repeat the test with the PostgreSQL server stopped or its network path blocked. Fineract should return an error to the client and should not serve cached or partial account data. Record how each component behaves, because the result depends on your identity provider settings, connection pool configuration and any reverse proxy in front of the API. If a test shows the platform failing open, treat it as a release blocker, confirm the fix with the owner of the affected component, and retest before any change reaches production.

Keep these checks as scripts in version control and run them after every configuration change and after each quarterly upgrade. The Fineract README states that official releases are created quarterly, so the upgrade run will recur on that cadence. Store each run's output with the date, the release tag and the configuration version so that a reviewer can compare results over time. Scripted tests verify the controls you have configured, but they do not replace independent penetration testing, which is a separate scope with its own rules of engagement. DeployOpen's security testing service covers applications, APIs, cloud and infrastructure, and can be scoped separately from this hardening work. Ask any assessor which controls they will test and how they will report findings, and agree that scope in writing before testing starts.

Hardening a Fineract deployment is a point-in-time state. Within a few months the default credentials may be back in a restored environment, a tenant header may be missing from a new integration, or a certificate may expire without anyone noticing. The operating evidence described here is what keeps the hardened state provable. Decide who owns each item before go-live, because monitoring and backups that nobody reviews do not count as controls when an assessor asks for them. Start with logs. Authentication failures on the OAuth2 and basic authentication endpoints, errors that carry a Fineract-Platform-TenantId value, and administrative changes such as new users, role changes, and configuration edits should flow to a central log store that the platform team cannot silently edit. Alert on bursts of failures, on any request that reaches a tenant it should not, and on admin actions outside change windows. Confirm with your SIEM team which fields they need, since tenant identifiers must be parsed reliably to be useful.

Configuration drift needs its own alert. Compare the running environment variables for each Fineract instance (write, batch and read) against the approved baseline, including SSL settings such as FINERACT_SERVER_SSL_ENABLED, the instance type settings, and the tenants database connection details. A change to any of these should open a ticket automatically. Drift checks are only as good as the baseline, so store the baseline in version control and review changes to it the same way you review code. Backups cover two databases: the PostgreSQL databases holding tenant data and the tenants database that maps tenant identifiers to connections. Losing either one breaks isolation in a way a file-level restore will not reveal. Schedule restore tests that go beyond checking that a dump file exists. A useful test restores into an isolated environment, confirms that each tenant's data is present and separate, and confirms that the access controls, roles and tenant mappings come back with the data. Record the result, the restore duration you measured, and who signed off. Ask your database team to confirm the backup retention period that your regulator or internal policy requires.

Rotation needs a schedule, not a reminder. List every credential the deployment depends on: database passwords, the service accounts used by batch and read instances, OAuth2 client secrets, API client credentials, and TLS certificates. For each one, record the owner, the rotation interval set by your policy, the procedure, and the test that proves the new value works before the old one is retired. Certificate expiry is the most common outage cause in this category, so track it with an alert well ahead of the expiry date. Upgrades are part of the evidence too. Fineract official releases are created quarterly, at the end of each quarter, and end-of-life releases are archived. Assign someone to review the upgrade notes for each release every quarter, check whether any security fix or configuration change affects your hardened settings, and decide whether to schedule an upgrade. Note that the current stable line, 1.15.0 according to the project website, may change, so confirm the latest release before planning. Liquibase migrations run only on write instances, so the review should identify which instance type the migration touches.

The security configuration document ties these items together. Map each hardening control to the test that verifies it, the evidence it produces, the owner, and the review frequency. A control such as HTTPS only should point to a configuration check, a scan result and a log of the last drift check. Keep the document under change control and update it when the release changes. This document supports the evidence an auditor will ask for, but it does not replace it. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors or certification bodies decide whether your controls meet a given standard. Ask your assessor which evidence formats they accept before you build the document.