Ta strona jest też po polsku →Эта страница есть на русском →
Security audit · pentest · Poland
A security audit that ends in fixes, not a PDF.
We check code, dependencies, servers and mobile apps the way an attacker would, prove each finding and fix it.
Built to find what fails quietly.
- 15typical findings below, anonymised and grouped by where the flaw lives
- 6layers checked, from the network edge to the backup
- 2agents on every finding: one finds it, the other tries to disprove it
Where an attack stops
The layers we check and set up. Pick one to see what it stops.
Edge
CDN · TLS
Stops
Floods, plain HTTP, direct hits on the server's address
How
TLS ends at the CDN, which filters floods. The server's address is never published, so there is nothing to hit around it.
Tunnel and firewall
0 open web ports
Stops
Port scans, attacks on exposed services, SSH password guessing
How
Web traffic comes in through an outbound tunnel, so no web port is open. The firewall is closed to the web; SSH takes keys only, passwords are off.
Proxy
limits · bans
Stops
Vulnerability scanners, request floods from one address, reads of internal files
How
Every address has a request budget per minute. A robot bans scanners that probe for known holes. Repository files answer 404, and security headers go out with every page.
Application
loopback only
Stops
Password guessing, access to someone else's data, injections
How
Services listen on loopback only. Three wrong passwords block an address for an hour. The server checks every permission again and encodes output for HTML, CSV and email.
Data
nightly, off-site
Stops
Lost disks, ransomware, human mistakes
How
A nightly archive goes to separate storage: seven daily copies and one per month. Databases are copied with a safe snapshot while they run.
Updates
monthly
Stops
Known vulnerabilities with public exploits
How
Once a month: OS packages, the kernel with a reboot, runtimes and dependencies. Each round goes into a written log.
What audits usually find
Composite cases, anonymised and altered: no client, product or date can be traced from them. Each comes with the fix and the rule that keeps it fixed.
High
A default admin password in the source codeCode
What we see
A fallback admin account is created from a password written in the code: anyone who has seen the repository signs in to a fresh install.
The fix
The first admin comes from a secret set at deploy time, and only while there is no other.
The rule
No credential in code, not even as a default.
High
Restricted items reachable through the public APICode
What we see
The API trusts the list the browser sends and never checks which catalogue the user is allowed to see.
The fix
The server checks the right on every request; restricted pages hand out a signed token.
The rule
The server checks every permission again; a button on a page proves nothing.
High
A runtime past its end of supportPackages and versions
What we see
Production runs a runtime and a framework whose security updates have ended: known CVEs apply, and no patch will come.
The fix
An upgrade plan ordered by exposure, tried on a copy, rolled out one service at a time.
The rule
Every runtime in the inventory has its end-of-support date next to it.
High
Repository files readable over HTTPInfrastructure
What we see
The web root mirrors the repository, so notes with access codes, scripts and tool configs are one URL away.
The fix
A deny rule at the proxy answers 404 for repository files; secrets move out of the web root.
The rule
If a folder is served, everything in it is public until a rule says otherwise.
High
An admin panel open to the whole internetAccess
What we see
The management page of a database or a storage box is reachable from anywhere, with only its own login form in front of it.
The fix
A VPN or a zero-trust gate with a one-time code goes in front of the login page.
The rule
Admin panels are not public pages, even behind a password.
High
Data folders outside the backupData and operations
What we see
Uploaded files, a database and service settings are never copied: the backup covers only what existed on the day it was set up.
The fix
Every data folder joins the nightly off-site archive, and a restore is tried on a schedule.
The rule
A service is not finished until its data is in the backup.
Medium
A spreadsheet export that runs formulas from user inputCode
What we see
A name that starts with = reaches the admin's CSV export as a live formula (CSV injection).
The fix
Cells that start with = + − @ are neutralised before export.
The rule
Output is encoded for where it goes: HTML, CSV, email.
Medium
One malformed cookie stops the service for everyoneCode
What we see
A cookie the parser does not expect throws an error outside any handler, and the process exits.
The fix
Defensive parsing and a last-resort error handler: the request gets an error, the process stays up.
The rule
Every input is hostile, headers and cookies included.
Medium
Dependencies with published vulnerabilitiesPackages and versions
What we see
Lock files pin libraries with known CVEs, and nothing tells the team when a new one appears.
The fix
A dependency check in CI fails the build on high severity; the rest goes into a weekly report.
The rule
A dependency is code nobody on the team has read: track it like your own.
Medium
Security patches installed but not runningPackages and versions
What we see
The kernel and system libraries are updated on disk, but the server has not restarted in months, and dozens of packages wait in the queue.
The fix
A monthly update round with a reboot, written into a log.
The rule
A patch counts once the process that needs it has restarted.
Medium
Old files that deploys never deleteInfrastructure
What we see
Deploys copy without deleting, so renamed folders, an old backup of an environment file and private documents stay on the server for years.
The fix
A report compares the server with the repository; leftovers go after a copy is taken.
The rule
Audit what the server holds, not what the repository says it should.
Medium
Sign-in forms that allow unlimited guessesAccess
What we see
Failures are not counted, passwords are compared in variable time, and session cookies go out without the Secure flag.
The fix
A temporary block after a few wrong passwords, constant-time comparison, Secure cookies.
The rule
Anything that checks a password also counts the failures.
Medium
A shared limit one visitor can use upAccess
What we see
Junk requests count towards a global cap, so a single address can lock real users out of a form.
The fix
The per-address limit runs first; the global cap counts only requests that passed validation.
The rule
A limit protects users; check whom it locks out.
Medium
A protection that is enabled but never runsData and operations
What we see
A timer that bans scanners is enabled at install and never started; for weeks only the rate limit stands in the way.
The fix
A dry run against the live log, then a start; status checks list every timer.
The rule
Enabled is not running: check the state, not the config.
Low
An error page cached for every visitorInfrastructure
What we see
A rate-limit answer inherits the long cache header of images, and the CDN serves that error to everyone.
The fix
Error answers are never cached.
The rule
Protection must not turn into a denial of service.
Nothing matches both filters.
How an audit runs
Every audit runs through the same pipeline: skills we wrote for AI agents, checks in CI, a person who signs off.
Scope and permission
We agree what is tested, from where, and what is off limits. Nothing starts without written permission from the owner.
You get: Scope letter
Inventory
Every runtime, framework, package and server, with its version and the date its support ends.
You get: Version map
Old versions
What is past support or has known CVEs gets an upgrade plan, ordered by exposure rather than by count.
You get: Upgrade plan
Code review by AI agents
Our skills split the review by flaw class: access control, injection, secrets, sessions, files, business logic. Agents read the code in parallel, one class each.
You get: Raw findings
Proof
Each finding is reproduced. A second agent tries to disprove it, and a person reviews what survives. What cannot be shown stays out of the report.
You get: Report with proof
Fix it, keep it fixed
Patches or pull requests, a retest, and checks in your CI pipeline, so the same flaw fails the build next time.
You get: Fixes and CI checks
What we audit
- Web apps and APIsOWASP ASVS · WSTG
- Sign-in and sessions, access control, injection, file uploads, limits, headers.
- Mobile appsOWASP MASVS · MASTG
- Android and iOS: stored data, network traffic, permissions, store policies. We publish 18 apps ourselves.
- Servers and networksCIS Benchmarks
- Open ports, tunnels, TLS, DNS and mail records (SPF, DKIM, DMARC), backups, updates.
- Code and dependenciesOWASP Top 10 · CWE
- Versions past support, known CVEs, secrets in the git history, the CI/CD pipeline.
- AI features and agentsOWASP Top 10 for LLM
- Prompt injection, data leaking through the model, which tools an agent may call.
What you get
- A report: each finding with its CVSS severity, CWE class, proof and steps to reproduce
- For each finding, a quick mitigation and the fix of the root cause
- Critical findings as soon as they are confirmed, not at the end
- An upgrade plan for old versions, ordered by risk
- Fixes: we patch, or hand the patches to your team
- A retest once the fixes are in
- Checks in your pipeline, so it stays fixed
Check yourself in a minute
Seven questions. The answers stay in your browser unless you add them to a request.
“Not sure” counts as a risk: what you cannot see, you cannot defend.
Questions before you order
Security audit or penetration test: what is the difference?
A pentest attacks a running system within a fixed time, the way an outsider would. An audit adds the code, dependencies, servers and processes, so it also finds what an attacker has not reached yet. We do both and say up front which one you get.
What do you need from us to start?
A list of what to test, access to a test environment and, if you can, the code. Testing starts only after written permission from whoever owns the systems.
Will you test production?
Only what you approve, at agreed hours and without destructive tests. A copy of production is better: there we can push harder.
Do you need our source code?
No. Without it we test from the outside, the way an attacker sees you (black box). With test accounts or the code (grey or white box) we find more in less time.
How much does it cost?
It depends on the scope. After your first email we agree on what is tested and send a price and a date before any work starts.
Will you sign an NDA?
Yes. We sign yours, or send ours together with the scope.
Who does the work, and who invoices?
Maxim Markarov with the studio's AI agents; every finding is checked by a person before it reaches you. Invoices come from a Polish sole proprietorship: JDG Maxim Markarov, NIP 8943181769.
Order a security audit
Tell us what to check. The request goes to support@markarov.dev, and a person replies from there.
- No autoresponder: the form cannot be used to send mail to someone else.
- No IP address is kept with your request.
- The form keeps the rules of this page: a limit per address, checks on the server, no third-party scripts.