Your site may be working perfectly today... and find itself in trouble tomorrow, without you having changed anything.
A “Too Many Requests” message, a slow site, a page that no longer responds: often, it’s not a bug, it’s the Internet intruding a bit too forcefully.
This is exactly what happened recently to our Odoo.sh instance: several requests per second on a simple blog page, traffic multiplied by ten, and Odoo started to suffer.
The difference is that this instance was not exposed “alone”: it was going through Cloudflare. By activating the mode“I’m Under Attack”, Cloudflare strengthened the controls and the instance was able to resume normal activity. The bots continued to hit, but the unwanted traffic was filtered before reaching Odoo.
This kind of scenario can happen to anyone, including small businesses.
This is exactly what we will see in this article.
1. The Internet does not only attack the “big”
We often imagine that attacks on the Internet target:
- banks,
- e-commerce giants,
- large, highly visible companies.
In reality, most of the time, it’s not even “humans” who attack, butautomated bots..
These bots:
- test addresses,
- visit random pages,
- try known vulnerabilities,
- sometimes send way too many requests at once.
If you have:
- a showcase website,
- an online store,
- an ERP like Odoo accessible via a browser,
then your system can be attacked, even if you are a small business, even if your traffic is modest.
For these bots, you are not “too small to interest someone”: you are simply another address on the Internet.
2. What needs to be protected: much more than the “small website”
When thinking about security, people often only think of the institutional site.
In reality, more and more critical components are online.
Odoo and ERPs
Odoo can manage:
- sales,
- purchases,
- inventory,
- invoicing,
- customer relationship (CRM),
- projects.
If Odoo is unresponsive, a good part of the business stops: no more data entry, no more visibility, no more invoicing.
PrestaShop, WooCommerce, Magento, Shopify
These solutions drive your online revenue:
- orders,
- payments,
- customer accounts.
If the store is unresponsive, that means lost sales and a damaged image.
WordPress and other CMS
WordPress often serves as:
- a showcase website,
- a blog,
- a lead generator,
- support for your brand image.
If it goes down or gets hacked, the impact is real, even if you don't "sell" anything online.
All these solutions are:
- very common,
- so very well known to those looking for vulnerabilities.
As soon as they are accessible on the Internet, they become visible.
3. The "digital guard": the idea of a frontal shield
Without protection, your site or your ERP is a bit like a store:
- open door to the street,
- no security guard,
- no management of the flow at the entrance.
Result:
- anyone can enter,
- come back 100 times a minute,
- ask "questions" that exhaust your cash register (your server),
- or simply block the passage by their presence.
A service likeCloudflare(and several other similar tools) acts like:
- a guard,
- a filter,
- an intelligent doorman.
This "digital guard":
-
Watches who arrives
- where the requests come from (country, ISP),
- how often,
- if the behavior resembles that of a normal visitor or a bot.
-
Slows down or blocks what is excessive
- if an address makes too many requests at once,
- if a behavior is suspicious,
- if the traffic comes from a less credible source.
-
Lightens the load on your server.
- by caching images, static files, etc.,
- to prevent the server from doing the same unnecessary work a thousand times.
At Auguria, this guard made a difference: Odoo.sh no longer received the flood of attacks directly.
It was Cloudflare that managed the wave upstream.
4. Two main types of problems, explained simply
To remain understandable, we can break down the risk into two main categories.
4.1. Too many people at once: the “bottleneck” effect
This is what causes messages like “Too Many Requests.”
This type of situation occurs when:
- there is a very large volume of requests at the same time,
- sometimes from many computers,
- sometimes from a few bots that simply send too many requests.
Effect:
- the server becomes overwhelmed,
- the site becomes extremely slow,
- or does not respond at all.
We often talk about DDoS attacks for this kind of scenario,
but what is important to remember is simple:
your server is overwhelmed.
In this case, the protectionsinsidethe site are no longer sufficient:
you need a toolupstream, which absorbs the volume and filters out the excess.
4.2. The “burglar” looking for a flaw
Second category of risk: intrusion.
The goal here is:
- to guess a password,
- exploiting a poorly protected form,
- installing malicious code,
- accessing data or administration.
This type of threat is addressed by:
- regular updates,
- good password management,
- internal security modules,
- hardening the configuration (permissions, access, etc.).
Here, we are more focused on protectionswithin the application.
Both families are important,
but they are not addressed with the same tools.
5. Shields to put in front of your site or ERP
Here are some examples of tools that play this role of “watchdog” in front.
The principle is always the same:
traffic first goes through them,
and only then to you.
Examples of front-end protection services
-
Cloudflare
A very well-known service.
It allows filtering traffic, protecting against volumetric attacks,
and speeding up site loading.
There is a free version that is already sufficient for many small businesses. -
OVHcloud (Anti-DDoS + CDN)
If your server is with OVH, the anti-DDoS is already part of the landscape.
It is possible to add additional caching and filtering services. -
Amazon CloudFront (with AWS Shield / AWS WAF)
For infrastructures hosted on AWS. -
Google Cloud CDN + Cloud Armor
For systems hosted on Google Cloud. -
Azure Front Door + WAF
For Microsoft Azure environments. -
Bunny.net, KeyCDN, etc.
Other simpler and often cost-effective services,
which also offer a 'shield' and a cache.
The key takeaway:
- these tools do not replace your website or your ERP,
- they sit in front,
- and they take the hit first.
6. Protections 'within' the site: useful, but different
Alongside front shields, there are protections within WordPress, PrestaShop, Odoo, etc.
They are important, but should not be confused with protection against a traffic 'bottleneck'.
WordPress
For example, you can find:
- Wordfence,
- iThemes Security,
- and other security plugins.
These tools allow you to:
- limiter les tentatives de connexion.
- detect suspicious files,
- block certain IP addresses,
- add captchas,
- monitor certain behaviors.
They are very useful for:
- reducing the risk of intrusion,
- making it harder to take control of the site.
However, it is important to state clearly:
- these plugins arenot designedto absorb a large volume of traffic,
- they are not an anti-DDoS solution.
Sur PrestaShop, WooCommerce, Magento…
Same logic:
- security modules,
- limiting login attempts,
- captchas,
- hardening access to the administration.
Again:
- very good for limiting intrusions and abuses,
- but it is not an “anti-bottleneck” solution.
Odoo
For Odoo, we are talking more about:
- user rights management,
- separation of environments (production / testing),
- careful configuration of access,
- setting up a reverse proxy (Nginx, Apache, Traefik…) to better control what is exposed.
These are necessary internal protections.
But for traffic volume attacks,
an external shield is needed as a complement.
In summary:
- front shield: manages volume and filters most of the traffic,
- internal protections: complicate life for attackers who have managed to breach the first barrier.
The two complement each other.
7. Where to start when you are not technical?
Here is a simple plan to follow, even without being a computer scientist.
Step 1: put a shield in front
Ask your provider or host:
- “Can we put a service like Cloudflare or an equivalent in front of my site / my Odoo?”
- “Does OVH offer a CDN + protection suitable for my configuration?”
Just this step already significantly reduces the risk.
Step 2: strengthen the entry points
Login and administration pages must be particularly well-designed:
- Odoo: access /web, /web/login, administration interface,
- PrestaShop, WooCommerce, Magento: back office,
- WordPress: /wp-admin, /wp-login.php.
Concrete ideas:
- limit the number of password attempts,
- enable captchas,
- use strong passwords,
- restrict administration access (by IP, VPN, etc., if possible).
Step 3: monitor weak signals
Some signals that should raise alarms:
- site suddenly very slow, for no reason,
- traffic multiplied by 5 or 10, without a marketing campaign,
- many requests coming from the same country or the same ISP.
These are not necessarily "good news":
it may mean that bots are paying a little too much attention to you.
Step 4: accept that risk concerns everyone
It's not about becoming paranoid, but about getting out of the illusion:"We are too small to interest anyone."
Internet bots do not care about the size of your business.
They test what is online, period.
8. And what about Auguria?
Auguria does not sell firewalls, security licenses, or cybersecurity solutions.
Our job is to:
help businesses structure and deploy their information system around Odoo,
so that this system is useful, clear, and manageable.
But the episode we experienced reminds us of a simple thing:
- a good information system is not just “well designed” functionally,
- it must also be protected, monitored, and able to hold up when the Internet wakes up on the wrong side.
Odoo, PrestaShop, WordPress, and other business tools are no longer just simple technical bricks.
They are critical assets.
The real question to ask at the end of the reading is this:
Today, your websites, your Odoo instances, your online stores:
are they alone facing the Internet,
or are they already protected by a true “digital guard”?
If the answer is not obvious,
it might be the right time to think seriously about it.