Security
We test the security of web and mobile applications, APIs and source code. We combine penetration testing with code and configuration review, basing the scope on OWASP Top 10, ASVS and WSTG, among others. You receive a report with vulnerabilities ranked by real risk and fix priority. If you'd like, we can also implement the fixes and run a retest.
Companies that trusted us
The basics
What a security audit gives you and how it differs from a penetration test
A web application security audit checks whether the application can be used in ways it wasn't intended: bypassing login, viewing other people's data, performing an operation without permission, extracting data from the database. The reference point is OWASP — the widely accepted list of the most common vulnerability classes. Penetration tests and audits are often confused. A pentest is a time-boxed attempt to break in: it shows what can be exploited right now. An audit is broader — it also covers configuration, permissions and dependencies, and answers the question of where the risk in the system lies. In practice, a well-run audit includes elements of both.
An audit is needed when the application processes personal data or payments, when a client or regulation requires it, when the vendor has changed and nobody knows what's inside, or simply before releasing a product to a wider audience. It doesn't replace ongoing hygiene: dependency updates, code reviews and backups, which are cheaper than any audit.
See a selection of projects we delivered
A home-cooked meals marketplace with Wolt delivery – selling your own food legally
Client: HomeChefs
Industry: Food Industry / FoodTech
Moving from mobile to web without losing users or business logic
Client: SkinApe
Industry: Entertainment / GameTech
„A key result was to increase marketing operation efficiency due to automated scheduling and budget management, which leads to better resource allocation for creative development. They are very familiar with the technologies in which they work, and can give good advice on these issues.”
Michał Słotwiński — Head of Customer Success, Semcore
Review from Clutch
How we work
How does an application security audit work?
We start by defining the scope: which parts of the application we test, which user roles we cover, which environment we use and which areas are out of scope. We usually run the tests in a test environment. If production needs to be checked, we agree on rules of engagement, a testing window and a contact person in advance. The result is a report listing the findings ranked by real risk, with a description of how to reproduce each one and a recommended fix. We can also implement the fixes and verify them in a retest.
On your side, we need access, the system owner's consent to the tests and someone who can respond quickly if needed. We sort out the formalities — the contract and NDA — before reconnaissance, not during it.
The timeline depends on the size of the application, the number of user roles and whether we have access to the code or are testing only from the outside. An audit with code access is more thorough and usually faster than testing blind.
Decisions
Decisions to make before and after an audit
With or without access to the code. Testing without knowledge of the system mirrors the situation of an outside attacker. Testing with code access finds more, and faster. If the goal is security rather than recreating a real attack, the second approach gives you more for the same money.
What to do with the list of findings. A report without implemented fixes doesn't change the level of risk — it only changes what you know. Budget for the fixes together with the audit, not next quarter.
How often. A one-off audit describes the state on a given day. An application developed every week moves away from that state immediately. It's cheaper to build reviews into the development process than to repeat a full audit.
What not to do. Don't test on production without an agreed window and a rollback plan. Don't publish details of findings before they're fixed. And don't treat compliance with a checklist as proof of security — they're two different things.
Scope
OWASP-based audits, with fixes done by us
Most audit firms stop at the document. We can go further: we implement the fixes ourselves, because we work every day in the same stacks we audit - from Next.js and Node.js to headless CMSs and applications running in Docker. There's no need to explain the report to another team or wait for them to find room for it in their backlog.
We also audit systems we didn't build. In fact, that's the most common case: someone else wrote the code and there's no documentation. In that case, we start with an inventory, not with testing.
Technologies we work with
- Focus area
We audit and harden applications built on the same stack we build with ourselves — Node.js and Next.js — along with their containerized environments in Docker.
Methodology
What an audit looks like: from reconnaissance to retest
1. Scoping — we identify the key parts of the application, user roles, the environment and the areas excluded from testing.
2. Reconnaissance — we learn the application's structure, API, integrations, permissions and where data is processed.
3. Security testing — we run manual tests supported by the right tools, using OWASP Top 10, OWASP ASVS and WSTG, among others. We report critical vulnerabilities as soon as we find them.
4. Report — we describe each vulnerability, its risk, how to reproduce it and the recommended fix.
5. Fixes — your team can implement them, or we can do it ourselves.
6. Retest — we recheck the vulnerabilities we found and confirm whether they've been successfully fixed.
How we work together
NDAs, access and testing safely
We can sign an NDA before any technical details are shared. We receive access only for the duration of the audit, and information about any vulnerabilities found goes only to the people you designate. We test primarily in a test environment. If the scope includes production, we agree on how we'll work in advance and exclude tests that could affect availability or data.
Throughout the audit, you're in touch with the person running the tests. If needed, we can stop them immediately.
The outcome
What you get after the audit
- Technical report. Each confirmed vulnerability includes a description of the problem, a risk rating, steps to reproduce and a recommended fix. We prepare the report so the development team can get to work right away.
- Fix priorities. Not every issue needs immediate action. We help you decide which vulnerabilities to fix first and which can be scheduled for later.
- Business summary. We also present the key findings in a form non-technical people can understand.
- Retest. After the changes are implemented, we recheck the vulnerabilities we found. If you'd like, we can also take care of the fixes beforehand.
FAQ
Questions we hear before an audit
- A pentest focuses on practically exploiting vulnerabilities and simulates an attacker's actions. An audit can have a broader scope, also covering code, configuration, dependencies and architecture. In practice, we often combine both approaches.
- It depends on the size of the application, the number of features and user roles, the scope of the API and access to the codebase. After a brief look at the system we can define the scope and timeline for testing.
- The cost depends mainly on the application's scope, the number of areas being tested and the chosen testing model. We agree on the scope before we start, so you know exactly what the quote covers.
- Not always. We can carry out tests without access to the code, but having it allows us to analyse the application more thoroughly and usually find the root cause of issues faster.
- We typically work in a test environment. If we test production, we agree on the scope, testing window and safety rules beforehand to minimize the risk to users and data.
- Yes. We're a development team, so we can not only identify the problem but also fix the code and verify the solution during a retest.
- A full audit is worth repeating after major application changes, architectural changes or before a significant release. For actively developed systems it's better to also build regular security reviews into the development process.
Let's build digital products for your company together
Other services
Web Development
We design and build custom web applications - from an MVP that lets you quickly validate an idea to large platforms and systems developed over years. We build both the front end and the backend, APIs, databases, admin panels and integrations with external systems. We work with Next.js, React, Node.js, NestJS, Python, PostgreSQL and MongoDB, among others. We create solutions tailored to a specific business process: SaaS applications, internal systems, sales platforms, websites, marketplaces and CMS systems.
Learn moreUX/UI Design
We design UX/UI for web and mobile applications and B2B systems - from analyzing user needs and early wireframes to the finished interface and a design system in Figma. We don't design screens in isolation from the product. We look at user journeys, analytics data and technical constraints to create a solution that's easy to use and can be built efficiently. After the product launches, we can come back to heatmaps, session recordings, analytics and user interviews, so that the next changes are driven by data, not assumptions.
Learn moreE-commerce
We design and build online stores and e-commerce platforms tailored to your sales model and business processes. We work with off-the-shelf solutions as well as headless architecture and custom sales systems. We build e-commerce for B2C and B2B sales, large product catalogs, multiple markets and marketplaces. We integrate stores with ERP, WMS, CRM, PIM, payments and logistics, and design product configurators and custom purchase flows. We also take care of performance, technical SEO and preparing the platform for seasonal traffic peaks.
Learn more