Web Application Security for Custom Apps, Portals and SaaS
Custom apps hold logins, records and business logic. We review and strengthen them so users and data stay safe.
What is web application security and how does it protect a custom app?
Web application security is the work of finding and fixing weak points in a custom app, such as a portal, CRM or SaaS tool, so users only see their own data and attackers cannot misuse logins, forms or settings. It covers code review, access checks, safe input handling, secrets and secure deployment.
Key takeaways
- Custom apps have no outside community checking their code, so planned reviews matter.
- Most real problems are access control, weak logins, unsafe input and leaked secrets.
- We review code and test on a staging copy, then report fixes in plain steps.
- Adding security at the design stage costs far less than fixing it later.
- Our parent team builds Laravel and React apps daily, so advice is practical.
Why does web application security matter for custom apps?
Web application security matters because a custom app holds logins, customer records and business rules, and no one else is checking its code. One weak spot can expose every user's data.
A custom web app, such as a customer portal, booking system, CRM or SaaS tool, is written for your business. That also means no one else is checking its code for bugs. Many apps are built fast to meet a deadline, and security steps get skipped.
Common problems include users who can see other users' records by changing a number in the address bar, forms that accept harmful input, weak password reset flows, and secret keys left in the code.
Security for custom apps is not only about attackers from outside. It is also about mistakes inside, such as a staff user who can delete records they should only read, or an export button that downloads all customer data with one click. We look at what each role can do and whether that matches what the business really needs. Small changes to roles and permissions often remove big risks.
What is included in a web app security review?
A web app security review covers seven areas: logins and sessions, access control, input handling, data protection, secrets, third-party packages and deployment settings.
| Area | Questions we ask |
|---|---|
| Login and sessions | Are passwords stored safely? Is two-factor login available? Do sessions expire? |
| Access control | Can a user only see and change their own data? Are admin pages protected? |
| Input handling | Are all forms and uploads checked on the server side? |
| Data protection | Is sensitive data encrypted? Are logs free of passwords and personal data? |
| Secrets and config | Are API keys and passwords kept out of code and version control? |
| Dependencies | Are libraries and packages up to date? |
| Deployment | Is debug mode off? Are error messages safe? Is the server hardened? |
We use widely accepted guidance, such as the OWASP Top 10 list of common web app risks, as a base for our checks.
Examples of issues we often find
- A logged-in user can open another customer's invoice by changing the ID in the link
- File uploads accept any file type, including scripts
- Password reset links never expire
- Admin pages are hidden but not protected by a role check
- Error pages show database details or file paths
- The .env file or a backup zip can be downloaded from the web
None of these need advanced attacks to misuse. That is why they are worth fixing first. If your app sits next to a public website on the same server, a broader security audit can check both together.
Code review vs vulnerability scan vs penetration test: which do you need?
Most small and mid-size apps need a mix: an automated scan for quick wins, plus a manual review of logins, roles and key flows. A deep penetration test is useful for apps with sensitive data or strict client demands.
| Option | What it does | Best for |
|---|---|---|
| Automated scan | Software checks for known issues and missing settings | Quick first look, regular checks |
| Secure code review | A person reads key parts of the code for logic and access flaws | Apps where code access is possible |
| Manual app testing | A person tests the running app with safe checks on staging | Finding access and business logic issues |
| Full penetration test | Planned, deep testing with written scope and permission | Apps with payment, health or other sensitive data |
If you are not sure where to begin, a vulnerability assessment gives a quick, low-cost start. It shows the obvious issues and helps decide if a deeper review is worth it.
How do we secure a web application, step by step?
We follow six steps: understand the app, review the code, test on staging, report fixes, help apply them and re-test. Each step is agreed with your team.
- Understand the app: users, roles, data and main flows
- Review key parts of the code with your permission
- Run safe tests on a staging copy where possible
- Report findings with examples and fix steps for developers
- Help fix issues, or review your team's fixes
- Re-test to confirm each issue is closed
Our parent team builds Laravel and React apps every day, so our advice is practical for developers, not just theory.
How long does it take?
A small app with a few user roles is often reviewed in one to two weeks. Larger apps with many modules, APIs and integrations take longer. Fixing time depends on your developers and the number of issues. We rank issues by risk, so the most serious ones are fixed first.
Laravel and PHP security: what to check first
For Laravel apps, check debug mode, the .env file, authorisation rules, mass assignment and package updates first. These cause most real issues we see.
- APP_DEBUG is false on the live server
- The .env file is outside the public folder and not in version control
- Policies or gates check that a user owns each record they open
- Models use $fillable or $guarded to block unwanted fields
- Composer packages are updated and old ones removed
- File uploads are checked for type and size and stored outside the public folder
- Queues, logs and storage folders are not open to the web
The same ideas apply to React front ends and Node.js back ends: never trust the browser, check access on the server, and keep secrets out of front-end code. When your app talks to other systems, see API security.
How do you build security into a new app from the start?
Plan roles, data handling and logging before coding starts. It is the cheapest time to add security, and it avoids costly rework later.
If you are planning a new app, the cheapest time to add security is before coding. We can help with secure design: roles and permissions, data handling, logging and API security. This avoids costly rework later.
- Plan user roles before building screens
- Use framework security features instead of custom code
- Keep a list of all third-party packages and update them
- Use a separate staging server for testing
Also plan where sensitive data will live. Customer records, payment references and documents need clear rules on who can see, export and delete them. Our data security service helps set these rules for the whole business, not only the app.
How much does web application security cost?
Web application security cost depends on app size, user roles, tech stack, code access and whether you want testing only or help with fixes. There is no fixed price; you get a clear quote after a free call.
Cost depends on app size, number of user roles, tech stack, access to code and whether you want testing only or help with fixes. You get a clear quote after a free call. For a quick start, a vulnerability assessment can find the most obvious issues first.
We also suggest simple habits for your development team, such as reviewing each other's code before release and keeping a short security checklist for every new feature.
Questions to ask any app security provider
- Will a person review the app, or only run a scanner?
- Do you test on staging, and how do you keep the live app safe?
- Will the report have clear fix steps my developers can follow?
- Is a re-test included after fixes?
- Do you understand our tech stack?
Common web app security mistakes to avoid
The most common mistakes are trusting the browser, skipping access checks, leaving debug mode on and never updating packages. Each one is simple to fix once found.
Good habits
- Check access on the server for every request
- Use framework login and password features
- Keep secrets in settings, not code
- Review code before each release
- Log important actions such as exports and role changes
Risky habits
- Hiding buttons instead of blocking access
- Writing your own password storage
- Sharing one admin login across the team
- Testing new features only on the live app
- Leaving old test accounts active
After launch, keep watching the app. Security monitoring can alert you to strange logins and unusual activity, so problems are caught early.
Frequently Asked Questions
Do you need access to our source code for a web app security review?
Code access gives the best results, because many access and logic issues are easier to see in code than from outside. If code access is not possible, we can still review the running app on a staging copy with safe checks. The report will say clearly what was and was not covered, so you know the limits.
Which technologies do you cover for web application security?
We mainly cover PHP and Laravel, WordPress, React and Node.js apps, which our parent team builds every day. We can also review many other common web stacks at the level of logins, access control, input handling and deployment. Tell us your stack on a free call and we will say honestly if we are a good fit.
Will you test on our live application?
We prefer a staging copy, so testing cannot affect real users or data. If only the live app is available, we use safe, read-only style checks, agree timing with you and avoid busy hours. We never run tests that could delete data or slow the app without your clear approval in writing.
What is the OWASP Top 10?
The OWASP Top 10 is a widely used list of the most common web application security risks, published by the Open Worldwide Application Security Project. It covers issues such as broken access control, injection and weak authentication. We use it as a base for our checks, then add checks specific to your app and business.
How long does a web app security review take?
A small app with a few user roles is often reviewed in one to two weeks. Larger apps with many modules, APIs and integrations take longer. The time to fix issues depends on your developers. We rank findings by risk, so serious issues can be fixed first while smaller ones are planned in.
Is a web app security review worth it for a startup?
Yes, especially before a launch, a funding round or a big client deal. Fixing access control and login issues early is much cheaper than after a data leak. Many business clients also send security questionnaires, and a recent review helps you answer them honestly. A small, focused review is a good start for most startups.
Can you fix the issues, or only report them?
Both. Some clients want a report for their own developers, with clear steps and examples. Others want us to fix the issues directly. Our parent team, Shivah Web Tech, builds Laravel and React apps, so we can make fixes in your code. Either way, we re-test to confirm each issue is closed.
Talk to our team today
Call or WhatsApp +91 85808 92163. We reply fast, Monday to Friday.