Planning a Customer Portal or Member Area

Start with who logs in and why

List the kinds of people who will log in and the one or two things each comes to do: a customer downloads invoices, a member reads members-only content, your staff upload documents or approve accounts. Writing these as short user stories keeps the first version small; our guide to writing a web app project brief shows how.

This list also tells you whether you need a portal at all. If every visitor sees the same content, a website is enough. If the most important screens are different for each person, you are building a web application, and web app vs website explains what that changes.

Then ask where the data lives today. If orders, bookings or customer records already sit in other software, the portal often shows them through that software's API rather than keeping a second copy. Our guide to APIs and integrations explains what to check.

Roles and permissions

A role is a named set of permissions, such as "customer", "support staff" or "administrator". Draw up a table with roles down the side, actions across the top (view orders, download documents, invite users, export data) and a tick where a role is allowed. Decide early whether one customer company can have several users.

The OWASP Authorization Cheat Sheet sets out the principles your developer should build to:

• Least privilege: each role gets only the access it needs.
• Deny by default: when no rule clearly allows an action, the answer is no.
• Check every request: OWASP says permission "should be validated correctly on every request", and warns that "an attacker only needs to find one way in". Hiding a button is not a permission check; the server must refuse the request too.
• Guessed IDs must not work: changing a number in an address, such as an invoice ID, must never show another customer's record.

Plan the lifecycle as well: how accounts are created (self sign-up, invitation, or approval by your team), how a user's role changes, and how access is removed when a customer leaves or a staff member moves on.

Passwords done the current way

Many portals still use rules that current guidance has dropped. The US National Institute of Standards and Technology's SP 800-63B (revision 4) is written for US federal systems but is a sensible model for any portal. It says:

• Passwords used on their own as the only sign-in factor must be at least 15 characters. Passwords used as part of multi-factor authentication may be shorter, but at least eight characters.
• No other composition rules "(e.g., requiring mixtures of different character types)".
• No forced password changes on a schedule, but a forced change when there is evidence the password has been compromised.
• New passwords are checked against a blocklist of "commonly used, expected, or compromised values".
• Password managers and autofill must be allowed, and pasting should be allowed.
• Failed attempts are rate-limited, and consecutive failures on one account are capped at no more than 100.

The NCSC's password guidance is a useful UK reference. Passwords must be stored with a proper password hashing scheme, never in readable form.

Passkeys and multi-factor sign-in

Passwords can be stolen through fake login pages; passkeys avoid that. The FIDO Alliance describes passkeys as "FIDO cryptographic credentials that are tied to a user's account on a website or application". The user approves the sign-in "with the same process they use to unlock their device (for example, biometrics, PIN, or pattern)". In the browser they work through the W3C Web Authentication (WebAuthn) standard, which defines public key-based credentials "for the purpose of strongly authenticating users".

Multi-factor authentication (MFA) means proving two different things, such as a password plus a code from an app. NIST's AAL2 level, which requires two factors, says systems "SHALL offer at least one phishing-resistant authentication option", and that syncable passkeys can meet AAL2. A practical plan for many portals:

• Offer passkeys to everyone, with a password as a fallback.
• Require MFA for staff and administrator accounts, which can see every customer's data.
• Let customers turn on MFA, and require it where the portal holds sensitive data or money moves.

OWASP's Multifactor Authentication Cheat Sheet compares the options, including SMS and email codes.

Password reset and account recovery

Recovery is a way into an account without the password, so design it carefully. OWASP's Forgot Password Cheat Sheet recommends:

• Show the same message, and take the same time, whether or not the account exists, so nobody can test which email addresses are customers.
• Send the reset through a separate channel, such as a link by email.
• Make reset tokens random, long enough, stored securely, single use and expiring after an appropriate period.
• Do not change the account, such as locking it, until a valid token is presented.

Also decide, and write down, what your team will do when a customer has lost both their password and their second factor.

Logging who did what

The OWASP Logging Cheat Sheet lists events worth recording, including authentication successes and failures and access control failures. For a portal, also record admin actions: who invited a user, changed a role or exported data. Decide who reviews the logs and how long they are kept, and keep passwords out of them.

Personal data and access requests

A portal almost always holds personal data, so data protection law applies. In the UK, Article 15 of the UK GDPR gives people the right to a copy of the personal data you hold about them. Article 12 says the response is free of charge, with exceptions for requests that are "manifestly unfounded or excessive", and that a request made electronically should be answered electronically where possible. Under Article 12A, the time limit is one month, which can be extended by two further months for complex or numerous requests if you tell the person within the first month and explain why. Our website privacy guide covers the wider basics.

So plan from the start how your team will find and export everything held about one person, across the portal and connected systems, including requests that arrive by email or phone. Collect only the data the portal needs, and decide how long you keep unused accounts.

Using OWASP ASVS as a checklist

The OWASP Application Security Verification Standard (ASVS) "provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development". OWASP also suggests using it "in contracts". The current version is 5.0.0, and each requirement has a numbered identifier, so you can point to exact items instead of writing "make it secure".

Ask your developer which ASVS level they will build and test to, and how the authentication, authorisation and logging requirements are covered before launch.

A planning checklist

• The kinds of users and the main task of each are written down as user stories.
• A roles-and-permissions table is agreed, with deny by default and server-side checks on every request.
• Password rules follow NIST SP 800-63B: length over complexity, a blocklist, password managers allowed, no scheduled changes.
• Passkeys are offered, and MFA is required for staff and administrators.
• Sign-ins, access failures and admin actions are logged, with no secrets in the logs.
• Your team can find and export one person's data within the legal time limit.
• The developer has named an OWASP ASVS level and shown how they will test against it.

Frequently asked questions

Do I need a portal or just a website?

If every visitor sees the same content, a website is enough. If people need to log in and see or change their own records, such as orders, documents or bookings, you are building a web application, and access control becomes the core of the design.

Should we still force users to change their passwords every few months?

No. NIST SP 800-63B says systems should not require periodic password changes, but should force a change when there is evidence a password has been compromised. It favours length, a blocklist of breached passwords and password managers.

What is a passkey?

The FIDO Alliance describes passkeys as FIDO cryptographic credentials tied to a user's account on a website or app. The user signs in by approving with the same method they use to unlock their device, such as a fingerprint, face or PIN. In browsers they work through the W3C WebAuthn standard.

Who should have to use multi-factor authentication?

At minimum, your staff and administrator accounts, because they can see every customer's data. Customers should be able to turn it on. NIST says systems at its AAL2 level must offer at least one phishing-resistant option.

How quickly must we answer a request for someone's data?

Under the UK GDPR, within one month of receiving the request, extendable by two further months for complex or numerous requests if you tell the person within the first month and explain why.

Planning a customer portal or member area? We build portals with access control checked on the server for every request and passwords stored with modern hashing, using the OWASP Top 10 as a baseline. See our web application development service and all our services, or email [email protected].