Mert 
Introduction
Modern applications exposed to the internet constantly face threats including SQL injection, bots, DDoS attacks, malicious traffic, and Layer 7 attacks.
OCI Web Application Firewall (WAF) helps protect internet-facing applications by inspecting and filtering HTTP/HTTPS traffic before it reaches backend applications.
What is OCI WAF?
OCI WAF performs Layer 7 traffic inspection, request filtering, threat detection, and policy enforcement before traffic reaches protected applications.
-> It acts like a security checkpoint for web traffic.
Why WAF Is Needed
✔ SQL Injection
✔ Cross-Site Scripting (XSS)
✔ Bot Traffic
✔ DDoS attacks
✔ Credential stuffing
✔ Malicious HTTP requests
Real-world Example
Attacker sends malicious SQL payload
→ Application vulnerable
→ Database compromise possible
WAF helps block malicious requests before they reach applications.
OCI WAF Architecture
Users
│
▼
OCI WAF
│
Traffic Inspection
│
▼
OCI Load Balancer
│
▼
Application Servers
Understanding Layer 7 Security
Traditional firewalls focus mainly on network traffic.
WAF focuses on HTTP/HTTPS application traffic.
-> OCI WAF operates at Layer 7 of the OSI model.
Layer 7 Examples
✔ URLs
✔ HTTP headers
✔ Cookies
✔ Request payloads
✔ API requests
✔ User agents
Request Inspection Workflow
Traffic Flow
OCI WAF Security Policies
WAF policies define how traffic should be inspected and filtered.
Examples
✔ Access rules
✔ IP blocking
✔ Country filtering
✔ Threat protection
✔ Rate limiting
✔ Bot management
✔ CAPTCHA challenges
Rate Limiting
Rate limiting controls excessive traffic requests.
Real-world example:
Bot sends 10,000 login attempts
→ WAF rate limiting blocks abuse
Bot Protection
Not all traffic comes from real users.
Bot Examples
✔ Credential stuffing bots
✔ Scraping bots
✔ Fake traffic generators
✔ Automated attack tools
-> OCI WAF helps differentiate legitimate traffic from automated malicious behavior.
OCI WAF Deployment Models
OCI WAF can be deployed in different architectures depending on traffic flow, security requirements, and application design.
Edge WAF
Traffic inspected closer to internet edge locations before reaching OCI infrastructure.
Regional WAF
Traffic inspection occurs within OCI regional deployment architecture.
Load Balancer Attached WAF
OCI WAF integrated directly with OCI Load Balancer for backend application protection.
WAF + Load Balancer Integration
Users
│
▼
OCI WAF
│
▼
OCI Load Balancer
│
▼
Backend Applications
WAF protects applications before traffic reaches backend infrastructure.
Real Enterprise Scenario
Example:
E-Commerce Platform
Users
→ WAF
→ Load Balancer
→ Web Servers
→ Payment Application
→ Database
Attack Example
Attacker sends malicious login traffic
→ WAF blocks suspicious requests
→ backend remains protected
Common WAF Challenges
✔ False positives
✔ Legitimate traffic blocked
✔ Poor rule tuning
✔ SSL misconfiguration
✔ Missing exclusions
✔ Excessively strict policies
Understanding False Positives
Sometimes legitimate application traffic may match security rules and become blocked accidentally.
Examples :
✔ Complex API payloads
✔ Encoded requests
✔ Search queries with special characters
✔ Custom application parameters
-> Effective WAF deployment requires balancing security and application usability.
WAF vs Traditional Firewall
| Traditional Firewall | WAF |
|---|---|
| Network traffic | HTTP/HTTPS traffic |
| IP/Port filtering | Application inspection |
| Layer 3/4 | Layer 7 |
| Infrastructure protection | Application protection |
Observability & Monitoring
WAF visibility is critical for security operations.
Monitoring Areas
✔ Blocked requests
✔ Attack patterns
✔ Bot traffic
✔ Request trends
✔ Security events
✔ Rate limit violations
Enterprise Best Practices
✔ Enable HTTPS inspection
✔ Continuously tune rules
✔ Monitor false positives
✔ Combine WAF with Load Balancer
✔ Enable logging
✔ Review attack trends
✔ Test security policies regularly
Understanding WAF Limitations
Although OCI WAF provides strong Layer 7 protection, it is not a complete replacement for secure application design.
✔ HTTP/HTTPS traffic only
✔ Requires rule tuning
✔ Cannot fully stop business logic abuse
✔ Secure coding still required
✔ Advanced attacks may bypass weak policies
Defense in Depth Security Architecture
Enterprise security should combine multiple security layers rather than relying on a single protection mechanism.
✔ OCI WAF
✔ OCI Network Firewall
✔ NSGs
✔ IAM Policies
✔ Secure Coding
✔ Vulnerability Scanning
✔ Logging & Monitoring
✔ Threat Detection
Conclusion
OCI WAF provides Layer 7 application protection by inspecting, filtering, and securing HTTP/HTTPS traffic before it reaches backend applications.
By combining threat protection, rate limiting, bot mitigation, and traffic inspection, OCI WAF helps organizations improve application security and operational resilience in modern cloud environments.
The Problem We Were Actually Solving
At first glance, the issue seemed to be about finding a suitable payment gateway that supported our business model. But the more I dug, the more I realized that the problem was deeper. Our e-learning platform was designed to be a global business, yet our payment infrastructure was tied to Western-centric platforms like PayPal and Stripe. These platforms didn’t provide a straightforward way for us to onboard customers from a country they deemed “high-risk.”
What We Tried First (And Why It Failed)
We tried to work around the issue by using alternative payment methods, such as bank transfers and cryptocurrency. However, these options introduced significant friction for our customers, and our sales numbers plummeted. We also considered creating a separate business entity in a country with fewer restrictions, but this approach would have required significant overhead and legal expenses.
The Architecture Decision
After months of research and experimentation, we decided to implement a custom payment gateway that leveraged local payment methods popular in our home country. We partnered with a regional payment processor that offered a seamless checkout experience for our customers. This decision required significant upfront investment, but it ultimately allowed us to bypass the platform restrictions imposed by PayPal, Stripe, Gumroad, and Payhip.
What The Numbers Said After
The results were eye-opening. By integrating a custom payment gateway, we reduced our payment processing fees by 40% and increased our conversion rates by 25%. Our customers were able to complete purchases with ease, and our sales numbers began to recover. The new infrastructure also gave us a competitive edge in the regional e-learning market, where many businesses struggled with similar payment restrictions.
What I Would Do Differently
In hindsight, I would have invested in a custom payment gateway much earlier in our platform’s development. I would have also explored more regional payment processors and alternative payment methods that could have helped us bypass platform restrictions. However, the key takeaway is that platform restrictions are not a reason to abandon your business goals. With the right architecture and engineering decisions, you can overcome even the most seemingly insurmountable obstacles.
Databasus just shipped restore verification. The idea behind it is short. A backup job that ends with “success” only proves the dump command ran. It does not prove you can restore the file it produced. Restore verification closes that gap. It takes your latest backup, restores it into a throwaway database container and checks that the data actually came back.
Databasus is the most widely used tool for PostgreSQL backup, and it already handles logical, physical and point-in-time recovery backups. Restore verification is the piece that now confirms those backups will actually restore. You can read the full feature docs on the restore verification page. The rest of this article covers what it does, how the report reads and how to switch it on.
A backup that finished is not a backup you can restore
Here is the uncomfortable part of running backups. Most setups check two things and call it done. They check that the backup job did not throw an error, and sometimes they check a file checksum. Both checks are real and worth having. The trouble is that neither one tells you the backup will restore.
A dump can exit with code 0 and still be missing data. A role without read permission on certain tables can make the dump tool skip those objects quietly. So can a missing extension on the source or a tablespace mismatch. None of that shows up in an exit code, and a checksum will happily confirm that an incomplete dump is a perfectly intact file.
| Signal | What it proves | What it still misses |
|---|---|---|
| Backup job succeeded | The dump command ran and exited without an error | Objects skipped because a role lacked read permission |
| Archive checksum matches | The stored file is intact, with no bit rot | Whether the dump is complete or can be restored |
| Restore verification passed | The backup restored into a live database and the rows are there | Nothing meaningful, since it runs the actual restore |
A green backup status and a matching checksum are both fine to have. They just leave one question open, and it is the question that matters most. Restore verification is the check that answers it directly.
What restore verification does
When a verification runs, it does not parse the backup or simulate a restore. It performs a real one. The sequence is the same every time, and it is easy to follow from start to finish.
Each run is self-contained. It never touches your production database, and it leaves nothing behind once the check is done.
Inside a real database container
The restore does not run against your live server. Databasus starts a separate Docker container for the job, on the host where the verification agent runs. That container runs the matching database engine, so the restore uses the real tooling instead of an approximation of it.
Running it this way has a couple of practical upsides. The check cannot interfere with production traffic, because it never connects to the production server at all. And since the container is disposable, a verification can restore a full database without you hunting for spare space on a real instance. When the run finishes the container and its data are deleted, so a week of daily checks will not slowly fill a disk.
This is the part the feature name points at. Your backup gets proven against a real engine in a real container, and then that container is thrown away.
Reading a verification report
Every verification leaves a report behind. At a glance you get a status, which is enough to see whether anything needs attention. Open the run itself and you get the detail, including exactly what came back from the archive.
| Field | What it shows |
|---|---|
| Status | One of Pending, Running, Successful, Failed or Canceled |
| Timeline | Every stage of the run with its own timestamp |
| Restore exit code | The exit code returned by the database’s native restore tool |
| Restored database size | The size of the restored database, checked against the backup |
| Schema and table counts | How many schemas and tables came back from the archive |
| Per-table row counts | A row count for each table in the restored database |
| Failure message | Shown at the top of a failed run, so the reason is the first thing you see |
The per-table row counts are the part worth watching. If a table you expect to be large comes back empty, the report shows it now, long before the day you actually need that backup to restore.
Turning it on with a verification agent
Restore verification is heavier than a normal backup job. It downloads a full backup, starts a database and runs a restore. Work like that does not belong inside the main Databasus container, so it runs on a small separate worker called the verification agent.
The agent is a single lightweight Go binary. You create it in the Databasus UI first, which gives you something to register against, then you launch the binary on a host you control. It dials out to Databasus, picks up verification jobs from a queue and reports the results back. You can run it next to Databasus or on a different machine, whichever suits your hardware.
Once it is running and registered, the agent appears in Databasus and starts taking jobs.
What the agent host needs
The agent does not ask for much, but it does have a few hard requirements. Most of them follow from the fact that it runs real databases in Docker. It is worth checking these before you launch it.
If a host already runs Docker and has some disk to spare, it can almost certainly run an agent.
Setting a resource budget
You will not want a verification to consume the whole machine, so the agent runs inside a budget. You pass four flags when you launch it, and Databasus divides that budget across the jobs it sends to the agent.
| Flag | What it limits | Example |
|---|---|---|
--max-cpu |
CPU cores the agent may use | 2 |
--max-ram-mb |
RAM in megabytes the agent may use | 2048 |
--max-disk-gb |
Disk in gigabytes available for restores | 20 |
--max-concurrent-jobs |
How many verifications run at the same time | 1 |
There is a floor of 1 CPU core and 512 MB of RAM per job. If your budget cannot cover that floor for the concurrency you asked for, the agent does not fail. It simply advertises a lower number of concurrent jobs and works within what it has. Set the budget once at launch and the agent stays inside it.
Schedules, the queue and notifications
You decide how often each database gets verified. There is no single right cadence, so Databasus gives you three ways to trigger a run, and you pick whichever fits the database in front of you.
0 4 * * 0 for every Sunday at 04:00The “after every backup” option raises a fair question. What if backups arrive faster than verifications can finish? Databasus handles that by cancelling any pending verification for a database as soon as a fresher backup shows up. Only the most recent backup waits in line, so checks never pile up and you always verify the newest data.
You can also run a one-off verification by hand. Each database has a “Restore verifications” tab, and from there you can start a single check without changing the schedule. It is handy for spot-checking one particular backup, or for testing a new agent right after you set it up.
Results can go to any notifier already wired to the database, so Slack, Discord, Telegram, email and the rest all work without extra setup. There are two separate toggles, one for verification success and one for verification failure, and they are independent of each other. Most teams switch on the failure one only, since a constant stream of “it worked” messages tends to get ignored after a while.
Set a trigger once, point it at the notifiers you already use and the database keeps verifying itself from there.
Conclusion
Restore verification changes what a backup status means. Instead of “the dump finished”, you get “the backup restored into a real database, and here are the row counts”. That is the difference between hoping a backup works and knowing it does.
Databasus is a free, open source and self-hosted backup tool, and it has become an industry standard for PostgreSQL backups. It is Apache 2.0 licensed, with more than 600,000 Docker pulls, around 7,000 GitHub stars and over 30 contributors. Restore verification ships in the same open source build as everything else, with no paid tier and no feature gate, and the code is all on GitHub.
If you already run Databasus, set up an agent and turn verification on for your most important database first. If you do not run it yet, this is one of those features worth having in place well before the day you actually need a backup to come back.