Wall & FifthSecure Development
Good software.
Stronger foundations.
Security starts with how a product is designed: the permissions, the data flows and the decisions behind every action.
The principle
The important work is often invisible.
A customer sees a login screen. Behind it are decisions about sessions, account recovery, permissions and the information that person is allowed to access. That is where secure product design becomes real.
Secure development means designing and checking the controls that protect an application. Authentication, authorisation, input handling and dependency management all need attention; the right scope depends on the product.
Identity & permissions
A login is only the beginning.
Signing someone in establishes who they are. Authorisation decides what they may do. A customer, a staff member and an administrator should not automatically have the same access, even if they enter through the same interface.
Restricted actions need permission checks on the server. Hiding a button in the browser is not an access control. For SaaS and marketplaces, record ownership and organisation boundaries also matter: knowing a record’s ID must not be enough to access it.
- Account lifecycle
- Consider registration, recovery, session expiry and removing access when someone leaves.
- Privileged actions
- Scope stronger controls for administrators and sensitive account changes.
- Permission tests
- Check what each role must be prevented from doing, as well as what it should be able to do.
Forms, files & APIs
Treat incoming data with care.
Every form, API call, integration and upload is a boundary where information enters the product. The application needs to check that the request is valid and that the caller is allowed to make it. Data validation, safe database queries and appropriate output handling address different parts of that problem.
File uploads deserve their own design. The allowed formats and sizes, storage access, download permissions and any malware-scanning requirement should be defined together. Scanning is one layer of protection; it cannot make every uploaded file safe.
For AI features, a model response is also untrusted input. Tool actions need server-side permissions, and retrieved information must remain within the user’s access rights. An AI assistant should never become a shortcut around the product’s existing controls.
Explore AI app developmentCode & dependencies
Control what becomes part of the product.
Application security includes the packages and services a product depends on. Dependencies need to be selected deliberately, reviewed for relevant vulnerabilities and maintained over the life of the software. A modern framework is a useful foundation, but its name is not a security guarantee.
API keys and other secrets belong in controlled server-side configuration, not in a public repository or a browser bundle. Access to deployment settings and production services needs the same care as access to the application itself.
Review & verification
Make the checks part of the scope.
The testing plan should reflect what the product could expose. Permission boundaries, important data flows and sensitive actions need checks beyond whether the happy path works. Code review, automated checks and manual assessment provide different kinds of evidence.
OWASP’s Application Security Verification Standard provides a public reference for specifying and testing application controls. If a defined ASVS level or independent penetration test is required, agree the version, coverage and evidence with the project team. Linking to a standard is not a claim of certification.
Clarity from the start
The right protection.
The right agreement.
Your product’s risks, controls and support needs belong in the project conversation. We’ll help you define the brief and identify what needs a separate assessment or specialist input.
Talk through your requirementsStraight answers
Before you
put your trust in it.
Does using React or Next.js make an application secure?
No framework makes an application secure by itself. Security depends on implementation, configuration, permissions, dependencies and ongoing operation. Framework choice is one architectural decision among many.
Will my product have multi-factor authentication?
That should be agreed for the relevant accounts and workflows. Administrator access, financial actions and sensitive data may justify stronger authentication. The method, recovery process and user experience need to be designed together.
Is a code review the same as a penetration test?
No. Code review examines implementation. A penetration test assesses a defined system for exploitable weaknesses within an agreed scope. They can complement one another, and neither guarantees that all vulnerabilities have been found.
How should an AI feature access private data?
The application should enforce the user’s permissions before retrieving data or executing an action. Prompts alone are not an access-control boundary. Sensitive tool actions, external content and model outputs need to be handled as part of the application’s security design.
Keep exploring