Fewer fake requests. More time for customers.
Form spam and suspicious login attempts weigh on the team and on day-to-day operations. Corpilus helps you assess risky requests and, depending on how it is connected, set how your application responds.
Three places where companies feel it most
Sample scenarios from running websites and e-shops. They are not client references and we quote no measured results with them.
Repeated fake enquiries
The contact form keeps delivering enquiries that read like politely written text. A real customer may be among them, so somebody has to go through them one by one.
A salesperson sorts requests that carry no value.
Why an enquiry was flagged and what a protected form does with it.
The script on the page reports how the form was filled in and whether the same text has already arrived many times over — not which words are in it. The binding decision comes only when the result is verified server-side, through the SDK or the token-verification endpoint.
Suspicious logins
The login page receives attempts with other people's passwords, logins from unknown devices and from places nobody could have travelled to between two attempts.
Risk of account misuse and a load on support.
The difference between assessing risk and the login application's own decision.
When the login process sends Corpilus a login together with its history, it gets a risk level with the concrete signals: impossible travel, repeated attempts with other people's passwords, a first login from an unknown device and an unknown country at once. The caller supplies the history, and your application decides about the login.
Automated content crawling
An automated client walks the catalogue while presenting itself as an ordinary visitor. In the statistics it looks like product interest, although no customer ever came.
Unclear origin of the traffic.
What could be recognised and where the integration allows an intervention.
The protection works with what it can see on its own side: whether the address appears on public IP-reputation lists, whether the user agent matches a known AI crawler, and whether the rules you configure apply. A match raises the risk and is recorded as an event; stopping the request is possible only on a route that verifies the result of the check.
You see the reason for the finding and the protection's response.
A single request from a protected form, as the event overview shows it.
- Time
- 08:07
- Place
- The “Contact” form on sample-shop.example
- Reason
- The same text arrived repeatedly from the same device; the fields were filled in all at once, with no typing.
- Risk
- High
The request was assessed and the event was recorded. The form processed it like any other — in this mode the protection does not step into processing.
Watching is a finding. It shows what reaches the website, but on its own it stops nothing.
The switch is here to demonstrate the difference. It changes only what you see in this sample and has no effect on any system's settings.
First we find out what your website needs.
No audit promised, and no automatic scan once you send an address.
- 01We pick what to protectWe go through the forms, the login or the interfaces you want protected — starting where it weighs on you today.
For ITThe scope is set route by route: which form, which login flow, which interface.
- 02We agree how it connects and what it watchesWe settle how the protection is connected and what it observes, so you can see what really reaches the website.
For ITOn a website that means the script on the page for the signals, and the SDK or middleware in your server-side flow for the binding decision.
- 03We set the responses to what we foundOnce there is something to go on, we set the responses one place at a time — first where the impact is largest.
For ITFor each surface we agree the severity from which a request is blocked, and what happens when the check is unavailable.
The script on the page alone does not enforce protection on the server. If the application is to stop a request, it has to verify the result of the check in the relevant server-side flow.
A protected form does not mean a protected catalogue — public browsing of content is a separate question. Recognising a known robot is also not the same thing as stopping content from being copied.
The website checks in detail
Only the checks that concern a website. Token verification, where the middleware sits, client-side bypass, outages and capacity belong to the integration and deployment pages.
Form signals
The script reports how the page and the form were used: whether the fields appeared all at once, whether the same submission repeats, and whether a hidden field a visitor cannot see was filled in.
Forms on pages where the script is deployed.
Request rate
Action events are assessed by the address determined on the server, not by a value taken from the request body. Telemetry from the script is left out of the rate checks and never leads to blocking.
Form submissions, logins and other action events.
Login assessment
The login-assessment endpoint evaluates impossible travel, repeated attempts with other people's passwords, a first login from an unknown device and country at once, and attempts against several accounts from the same address or device. It returns risk and signals, not a verdict.
Called from the login process through the integration or the REST API.
Rules and the available responses
For each surface — form, login, API — the policy sets the severity from which a request is blocked. It only ever tightens the decision of the other layers, never loosens it, and with nothing configured it enforces nothing extra.
Evaluation of events from the script and the SDK.
Outside-in website scan
On request it walks the website as a visitor, with HEAD and GET requests only, no attacks and no form submissions: the encryption and security-header setup, cookies, publicly reachable files, cross-domain sharing and the rules for AI crawlers.
A separate check, not an automatic scan triggered by an address.
If you have a WAF, Corpilus neither replaces it nor switches it off. Which places it still adds a check to is a question to go through layer by layer. WAF and other layers
Let's look at the specific place that is giving you trouble.
Send us the address of the website and describe briefly whether it is the forms, the login or another part of the application. We will propose a suitable way to assess it.
Sending an address is not consent to active security testing. We start no automatic scan once an address arrives.
The price is individual, by scope. How the scope is determined