ACCESS01
Missing access control
The endpoint checks whether the user is logged in, but does not verify whether they are authorised to perform the action.
Security testing for AI-built applications
Before you deploy an AI application, make sure it is secure
We test applications, websites and online stores built with AI and vibe coding. We run the code in an isolated environment, identify vulnerabilities and deliver a clear remediation plan.
AUDIT WORKFLOWTEST ENVIRONMENT
CODE REVIEWDEPENDENCIESAPI AND ACCESS TESTSREMEDIATION PLAN
The most serious flaws often do not break the application
The form saves data, the API returns a response and login works. The problem starts when another user can perform the same action, read someone else’s data or bypass validation.
DEPS02
Vulnerable libraries and dependencies
The project uses packages with known vulnerabilities or outdated components whose risk has not been assessed.
SECRETS03
Secrets stored in code
API keys, tokens or passwords end up in the repository, container image or browser-accessible code.
INPUT04
Incorrect input validation
The application trusts form or API input, allowing an attacker to alter query logic, user roles or the scope of an operation.
API05
Unsecured API endpoints
A function visible only in the admin panel may still be accessible through a direct API request.
IDOR06
Access to another user’s data
Changing an identifier in the URL or request makes it possible to retrieve a record belonging to another account.
WHAT WE TEST
Access control, input validation and application behaviour outside the expected path
WHO IT IS FOR
For projects before launch or a major change
An audit is worthwhile when the code was built quickly, relies on many dependencies or has not undergone an independent security review.
TO GET STARTED
You do not need an in-house security team.
To start the audit, we only need:
- Project code
- Setup instructions
- Description of key features
WHEN TO REQUEST A TEST6 EXAMPLES
SaaS application owners
When the product handles accounts, payments or customer data.
Startups before launch
When the MVP is about to reach its first users or an investor.
Teams using vibe coding
When the code was built quickly without a full security review.
MVP and prototype creators
When a prototype starts becoming a production product.
Online store owners
When the system processes orders, customer data and integrations.
Software houses
When an independent review is needed before project acceptance.
TEST SCOPE
We test the code and application behaviour
OWASP TOP 10OWASP APICWE
Standards structure our work. We describe each finding in terms of the problem, impact and fix.
TEST AREAS 12 MODULES
01CODESource code review✓
02APPApplication and API testing✓
03AUTHAuthentication and sessions✓
04ROLEAuthorisation and permissions✓
05DATAAccess to other users’ data✓
06DEPSDependencies and known vulnerabilities✓
07KEYSecrets stored in code✓
08ENVEnvironment configuration✓
09INPUTInput and form validation✓
10FILEFile uploads and handling✓
11ERRORErrors and information disclosure✓
12RISKHigh-risk code sections✓
HOW WE WORK
How the security audit works
Before we begin, we agree on the scope, code transfer method, features covered by the test and the date on which the environment will be removed.
- 01STEP 01
Code transfer
A repository, project archive or temporary code access together with setup instructions.
- 02STEP 02
Application setup
We run the project locally in an isolated Docker environment using test data.
- 03STEP 03
Analysis and testing
We review the code, configuration, dependencies, API and the application’s most important workflows.
- 04STEP 04
Findings report
We document vulnerabilities, evidence, risk, potential impact and a specific remediation method.
- 05STEP 05
Retest
After the fixes are implemented, we retest the reported issues and update their status.
SAMPLE REPORTA report your developer
A report your developer
can act on immediately
Every finding is described in the context of the application. The report shows the location, reproduction steps, potential impact and recommended fix.
SUMMARY
Analysis results
2Critical findings
4High-risk findings
7Medium-risk findings
5Code quality recommendations
VS-IDOR-01HIGH RISK
A user can retrieve another account’s data by changing the identifier in the API URL
ISSUE DESCRIPTION
The endpoint validates the session but does not compare the account identifier with the user making the request. Changing the parameter returns a record belonging to another organisation.
POTENTIAL IMPACT
Exposure of another customer’s profile data, billing history and settings.
RETEST STATUS
Pending verification after the fix
Critical High Medium Low
DELIVERABLES
What you receive after testing
The result helps you prioritise work, assign tasks to the developer and make an informed deployment decision.
RESULTFindings prioritised by project risk.
- 01
PDF report
- 02
Findings grouped by risk level
- 03
Identification of vulnerable files and code sections
- 04
Steps to reproduce every issue
- 05
Remediation guidance for the developer
- 06
Summary for the project owner
- 07
Option to discuss the findings
- 08
Optional retest after fixes
Credibility and experience come first
VernoSec is a service by NetCoding.pl
Testing is performed by a NetCoding.pl full-stack developer working across 17 programming languages. He has more than 20 years of software development experience, including 17 years delivering web projects. The report covers not only the vulnerability, but also where to fix it and how the change affects deployment.
Visit NetCoding.pl17years delivering
web projects
web projects
20+years working as a
software developer
software developer
17programming languages
used in full-stack work
used in full-stack work
CONFIDENTIALITY
Your code remains under control
We run the project locally in an isolated environment. Only the people conducting the test receive access to the code. Data retention and deletion rules are agreed before work begins.
NDA
We can agree and sign confidentiality terms before the code is transferred.
TRANSFER
Together we choose a secure way to transfer the repository or archive.
ACCESS
Access is limited to the people and resources required to perform the test.
CLEANUP
After completion, we close the environment and delete copies according to the agreed schedule.
FAQ
Frequently asked questions before testing
Essential information about preparing the code, environment and test data.
You can share a private repository, provide an encrypted archive or agree another secure channel with us. Before testing, we confirm the access scope and copy deletion date.
BEFORE DEPLOYMENT
Test the application before someone does it without your permission
Send us the basic project details.We will respond with a proposed test scope and price.
CONTACT
Describe the project and we will define the right test scope
To begin, describe the technology, project stage and features that need the closest review. You can also indicate the planned code transfer method or add a repository link.
!
Do not send passwords, API keys, tokens or production data. We will arrange a secure code transfer method separately.
Email: contactvernosec.com