Web application development company in India
We build web applications with sign-in and roles, most often in React and Next.js. We put the access check inside the server code that reads or changes data, not only in the page, because a request can skip the page. Our security team reviews our builds before launch.
Built into the app
Every app makes these six choices, on purpose or by accident. We make them with you before the build, following guidance from Next.js, React and OWASP.
A trusted backend service (server code, not the browser) verifies every session token, the proof that a user signed in. OWASP ASVS 5.0.0 (the Application Security Verification Standard) lists this as v5.0.0-7.2.1, a Level 1 requirement.
OWASP's Authorization Cheat Sheet wants access denied unless a rule allows it. So a new screen, role or record starts closed.
Every Server Action, Server Function and Route Handler (the server code behind a form, a button or an API address) checks its own caller, so a request that skips the page still meets the check.
Who may do what is written once, in one place, and every action calls it. Changing a role means changing that one place.
Each action sends the browser the fields the screen needs, not whole database records. Anything sent can be read by the person using the browser.
Next.js's data security guide notes that environment variables (settings such as service addresses and secret keys) prefixed NEXT_PUBLIC_ reach the browser. So the prefix decides what the browser can read, and we choose it on purpose.
Not sure whether to build or buy? See custom software development. Need a phone app as well? See mobile app development.
Where the check lives
Signing in shows who someone is. It does not show whether they may see or change this record.
A signed-in page with an edit form looks guarded. Only the page is. Saving the edit happens in a Server Action, a Server Function or a Route Handler, and a request can call any of them without loading the page. So in web application development with React and Next.js, each of the three has to check its own caller. Next.js's Server Actions guide says showing a form only on a signed-in page is not a security boundary, because requests can skip the UI (the screen).
Next.js's data security guide separates being signed in from being allowed to act on a particular record. Only code that knows which record is involved can decide the second. So Next.js's Authentication guide wants most security checks as close to the data source as possible. Authorization rules (who may do what) belong on a trusted service layer, in server code the caller cannot change. OWASP ASVS 5.0.0 lists this as v5.0.0-8.3.1, a Level 1 requirement.
Next.js's proxy.js reference warns: “A matcher change or a refactor that moves a Server Function to a different route can silently remove Proxy coverage.”
Beyond Next.js
Framework authors outside React and two Indian government documents add their own instructions. CERT-In is the Indian Computer Emergency Response Team; GIGW 3.0 sets the guidelines for Indian government websites and apps.
| Publisher | What it tells a build | Where |
|---|---|---|
| Angular documentation | Enforce authorization server-side, not in guards alone | Control route access with guards, marked CRITICAL |
| Ruby on Rails Guides | Any parameter can be changed, however well hidden | Securing Rails Applications, 6.6 Privilege Escalation |
| Laravel documentation | Always handle authorization on the server | Authorization & Inertia |
| Django REST framework | Generic list views skip per-object permissions | API guide, Permissions |
| CERT-In | Revalidate server-side what the client validated | Application security guidelines, section 4.16 |
| GIGW 3.0 | Secure, HTTP-only cookies; role-based least privilege | Guideline 5.3.1, Developer action (e), (l) |
How we build it
We settle who may do what before the build, then build the check into each piece of server code.
We write down the roles and what each one may read or change. OWASP's Authorization Cheat Sheet says to decide authorization requirements first, then assess third-party components, such as a sign-in library, against them.
Next.js's data security guide recommends one data-fetching approach, not a mix, so developers and security auditors know what to expect. For new projects it recommends a dedicated Data Access Layer: one part of the code that all data access goes through.
Each function runs those rules against whoever is calling it. A check placed inside the function moves with it when the code is reorganized.
Our security team checks the finished build before real users and data arrive. See what the pre-launch review covers.
Scope
Three related questions each have their own page.
When one product serves many customer companies, each customer's data must also be kept apart from the others. That belongs to SaaS development.
What the caller is told when the check fails, such as 403 (not allowed) or 404 (not found), belongs to API development and integration.
Assessing a running web application for vulnerabilities, including one someone else built, is a separate service: web application vulnerability assessment.
Not a “safe to host” audit. GIGW 3.0 says government organizations must get that certificate from auditors empanelled (officially listed) by CERT-In or STQC, or from STQC or NIC. SecWiz is none of those, so our pre-launch review does not replace it.
FAQ
Each answer cites the publisher's own guidance. For anything else, ask us directly.
No. Next.js's data security guide says an exported Server Action can be reached by a direct POST request, not only through the interface, and React's 'use server' reference says a Server Function's arguments are entirely under the client's control. A hidden button changes neither, so the action has to check its own caller.
No. Next.js's Authentication guide warns that, because of Partial Rendering, layouts do not re-render when a user moves between routes, so the session is not checked on each route change. The same guide says a layout does not control whether the rest of the route renders. Pages and Server Actions under it need their own checks.
No. Next.js renamed middleware to proxy in v16.0.0. Next.js's Authentication guide marks checks in Proxy as optional and groups them with checks that read session data from the cookie rather than from the database. The check that decides whether a caller may change a record still belongs inside each Server Function.
Both. OWASP's Authorization Cheat Sheet prefers access-checking technology set up once for the whole application, rather than applied to every method or class. Next.js's data security guide recommends a dedicated Data Access Layer for new projects, and React's 'use server' reference has every Server Function confirm that the logged-in user may perform the action. The rule lives in one place; every action calls it.
Yes, when the owner is a government organization. GIGW 3.0 requires every website and app such organizations own to comply, and recommends its guidelines for browser-based intranet applications too. GIGW 3.0 says government organizations must obtain a "safe to host" certificate from auditors empanelled by CERT-In or STQC, or from STQC or NIC, and SecWiz is none of those.
Only what the screen uses. Next.js's data security guide notes that whatever a Server Action returns is serialized and sent to the browser, and says to return what the UI needs, not raw database records. OWASP ASVS 5.0.0 lists returning only the required fields of a data object as v5.0.0-15.3.1, a Level 1 requirement.
Let's talk
Already running an app? Name the framework it runs on and which of its entry points check the caller. Project work is delivered remotely from India during business hours. We reply within one working day.