Established stack.
Fresh questions.

The language alone does not determine security

A PHP application can be well designed or can contain weaknesses in its own code, dependencies, or deployment configuration. The starting point is the application and the access it exposes. A framework name or a long history in production is not evidence that every route enforces the intended rules.

Follow input to the action it controls

Within the agreed target, selected checks may examine SQL injection, stored or reflected XSS, unsafe uploads, path handling, and command or code-execution risks. The report should establish the affected path and conditions, rather than treating every suspicious response as a confirmed exploit. Destructive testing and persistence are excluded by default.

Test accounts, sessions, and ownership

A session establishes a user’s identity; each sensitive action still needs the correct authorization. Approved accounts with different roles can help assess cross-account data access, admin boundaries, password-reset flows, and session behavior where those areas are in scope. Custom scripts, APIs, and legacy routes can have different controls from the main interface.

Agree what can be reviewed safely

Source-code review, dependency inventory, server configuration, and a deployed website check have different access and coverage requirements. We agree those activities individually. Use test data where possible, define backups and a stop contact, and identify third-party components before testing. Remediation and retesting are separately scoped so the next step is clear.

A few practical answers.