Muhammad Yasir Amin

Loading website…

More from Muhammad Yasir Amin

Build Along With Me

Practical walkthroughs on Laravel, React, APIs and deployment workflows.

Subscribe on YouTube

🚀 Practical Best Practices Every Developer Should Follow

🔐 Security & Best Practices5 min read

🚀 Practical Best Practices Every Developer Should Follow

Muhammad Yasir Amin

Muhammad Yasir Amin

Senior Full Stack Engineer•May 10, 2026
🚀 Practical Best Practices Every Developer Should Follow

A security checklist becomes useful when it explains which request crosses a trust boundary and how to verify the result. A Laravel API and a React frontend have different responsibilities: the browser can help a user enter valid data, while the server must enforce what it accepts and who may perform an operation.

The examples below use Laravel 12 and a React/TypeScript client. They are small implementation patterns, not a claim that adding one middleware or using an ORM makes an application secure. Apply each pattern to the actual authentication, content and deployment model of your application.

Validate the request on the server

Frontend checks improve feedback, but a client can bypass them. Validate required fields, lengths, types and permitted values again in Laravel. Use the validated payload when creating a record instead of passing every incoming field to a model.

PHP
$validated = $request->validate([
    'name' => ['required', 'string', 'max:255'],
    'email' => ['required', 'email', 'max:255'],
    'message' => ['required', 'string', 'max:5000'],
]);

ContactLead::create($validated);

This illustrative contact-handler fragment assumes the model's fillable fields and authorization match the endpoint. An email rule checks the submitted address's format; it does not prove ownership. Likewise, a maximum message length bounds the field without preventing every form of spam.

In this portfolio's contact flow, browser validation provides prompt feedback and Nucleus is the server-side write boundary. Keep both contracts aligned when a field changes. Test a direct HTTP request with invalid data, rather than testing only the browser form.

Separate authentication from authorization

Authentication identifies a caller. Authorization decides whether that caller can act on the selected record. A token-authenticated route still needs resource-specific permission checks. Do not trust an account ID supplied by the client as proof that a record belongs to that account.

PHP
Route::middleware('auth:sanctum')->group(function () {
    Route::patch('/documents/{document}', function (
        Request $request,
        Document $document
    ) {
        Gate::authorize('update', $document);
        $validated = $request->validate([
            'title' => ['required', 'string', 'max:255'],
        ]);

        $document->update($validated);
        return response()->json(['success' => true]);
    });
});

This is a pattern, not a ready-made endpoint in Nucleus. It requires the application to implement and register a Document policy, the model and imports. Verify it with two users: one permitted to update the document and one who must receive a denial. An anonymous request should also be rejected.

Use query bindings instead of interpolating SQL

A value such as an email address belongs in a parameter binding, not in a string concatenated into SQL. Eloquent and the query builder bind ordinary values:

PHP
$user = User::where('email', $validated['email'])->first();

Raw expressions still require care. A user-supplied column name or sort direction is not an ordinary bound value. Map sorting options to a fixed allowlist and reject unknown choices. Do not assume that using an ORM makes every raw query safe.

Treat plain text and rich HTML differently

Rendering a string as a normal React child escapes it. Rendering CMS HTML with dangerouslySetInnerHTML or parsing it as HTML crosses a different boundary. A rich-text pipeline needs a deliberate allowed-element, attribute and URL policy; it should preserve useful code and images while rejecting executable markup and unsafe links.

TypeScript
// A plain-text field:
<p>{message}</p>

Test rich text with script tags, event-handler attributes, unexpected iframes and unsafe URL schemes, as well as legitimate code blocks. Input validation such as string|max:5000 does not sanitize HTML. Restricting editing to administrators reduces exposure, but does not make imported content automatically trustworthy.

Match CSRF protection to the authentication flow

A Laravel web session relies on cookies, so state-changing web requests need Laravel's CSRF mechanism. Sanctum's first-party SPA flow has its own cookie and CSRF setup. A third-party client using a bearer token is a different flow; blindly adding a hidden form field does not solve its token-handling responsibilities.

Follow the framework's flow end to end. Keep session cookies and tokens out of public HTML, client logs and source control. Test an expired session and a missing or invalid CSRF token for the web flow. Test a missing or revoked bearer token for the token flow.

Bound public requests and uploads

Public forms need a reasonable request limit and a useful response when that limit is reached. A per-IP throttle is one layer, not a complete abuse strategy: shared networks and distributed clients complicate its behavior. Validate upload size and actual supported media types on the server, and decide which files are public.

Store uploaded files through an owned attachment record so cleanup can distinguish a removed image from an unrelated asset. A public storage URL should never be used for private documents just because it is convenient. Confirm access behavior with a direct URL request as well as the application's download button.

Keep operational checks reproducible

Use supported dependencies and inspect dependency advisories as part of maintenance. Keep credentials in server configuration and avoid including request bodies or authorization headers in diagnostic logs. Record enough information to investigate failures without turning logs into a copy of users' submissions.

A useful release check covers invalid fields, unauthorized users, revoked tokens, unsafe rich text, oversize uploads and rate-limit responses. Run those checks in an isolated environment with fake mail and storage where appropriate. Then verify the deployed routes separately; local success does not establish the production configuration.

Security improves when each boundary has an explicit rule and an observable failure. A short, tested request contract provides more value than a long checklist of tools that the application has not actually configured.

Framework references

See the Laravel 12 guides for validation, authorization, Sanctum and CSRF protection. For plain-text and HTML rendering behavior, see React's HTML rendering reference.

Article Index & Topic Tags
LaravelWeb-SecurityPhpBest-PracticesOwaspSql-InjectionXssDeveloper-Guide

YouTube Channel

Build Along With Me

Practical walkthroughs on Laravel, React, APIs and deployment workflows.

Muhammad Yasir Amin
Available for Contracts
Author & Solutions Architect

Senior Full Stack Engineer

Independent Senior Full Stack Engineer working on Laravel, React and Next.js applications, APIs and delivery workflows.

Laravel & PHP ApplicationsReact & Next.js InterfacesREST APIs & IntegrationsDatabase Queries & DebuggingDocker Development WorkflowsClear Scope & Handover
Discuss Your Next Step

What Does Your Application Need Next?

Share your current system, the problem you want to solve and what a useful result looks like. We can identify the right starting point and agree on a practical scope.

Technical Audit

Find the Next Useful Fix

Application Development

Scoped, Reviewable Milestones

Ongoing Support

Agreed Capacity and Priorities

Share your goals, current stack and requirements before the call.