Missing Boundary Checks: Why “Nice” Code Always Gets Exploited

When you don’t validate inputs, don’t be surprised when the system gets abused.

Context

In my previous refactor, I removed a core anti-pattern:

Default behavior:
→ say yes
→ be available
→ be helpful

That fix exposed something deeper.

The real issue wasn’t just over-availability.

It was the absence of boundary checks.

The Bug: No Input Validation

For a long time, my system operated like this:

Incoming request → accept → execute

No filtering.
No validation.
No consideration of cost.

Everything got processed.

Requests, expectations, emotional load—queued and handled in real time.

I thought this made me “reliable.”

In reality, it made me unprotected.

What Happens Without Boundary Checks

In software, if you don’t validate inputs, two things happen:

Bad data gets in
The system becomes unpredictable

Human systems behave the same way.

Without boundaries:

unreasonable requests feel normal
disrespect gets reclassified as personality
urgency is assigned by whoever asks first

You don’t control the system anymore.

You just maintain it.

The API Problem: People Probe for Limits

Here’s the part I didn’t understand before:

People don’t always consciously exploit you.

But they do test for limits.

Like hitting an API endpoint:

Request → response
Adjust → request again

If the system always returns:

200 OK

Then the behavior escalates.

small asks become bigger asks
favors become expectations
access becomes assumed

Not because people are malicious.

Because the system allowed it.

The “Nice” Misconfiguration

I had configured my system like this:

Boundary checks: disabled
Rate limiting: none
Access control: open

And then I was surprised when:

I felt drained
people expected more
saying no felt disruptive

But from the outside, the system was working exactly as designed.

The Cost of No Validation

1. Priority Corruption

Without boundaries, your priorities get overwritten by external input.

Whoever asks first—or loudest—wins.

1. Silent Resentment

When you say yes against your own capacity, the system logs it:

Accepted request ≠ aligned decision

That mismatch turns into resentment over time.

1. Identity Drift

If everything gets accepted, nothing is chosen.

And if nothing is chosen, you disappear from your own decision-making.

The Fix: Implement Boundary Checks

I didn’t try to “be less nice.”

I added validation.

1. Request Evaluation Layer

New flow:

Incoming request
→ evaluate (Do I want this? Do I have capacity?)
→ optional response

Not everything passes.

1. Explicit Rejection Handling If (request ≠ aligned) → return: No

No long explanations.
No defensive reasoning.

Just a clean response.

1. Access Control

Not everyone gets the same level of access.

Access levels:

• earned
• limited
• revoked

This used to feel harsh.

Now it feels accurate.

1. Rate Limiting

Immediate response is no longer the default.

Response time = intentional

Urgency is no longer assigned externally.

What Changed

Once boundary checks were in place:

fewer bad inputs reached execution
expectations recalibrated
some “users” stopped making requests altogether

That last part matters.

When a system stops being easy to exploit, it stops attracting exploitative behavior.

Reframing “Nice”

The old model:

Nice = always accessible

The updated model:

Respectable = selective + clear

And a hard truth:

If your system never rejects a request,
it’s not kindness.

It’s misconfiguration.

Takeaway

Boundaries aren’t about controlling other people.

They’re about defining what your system accepts.

If you don’t implement boundary checks, the world will write your rules for you.

And it won’t optimize for your well-being.

Status
Boundary checks: enabled
Default response: not guaranteed
System integrity: improving

Series: Behavioral Anti-Patterns

Previous: Deleting the “Nice” Anti-Pattern
Next: Unbounded Processes: The Hidden Cost of Always Saying Yes

Comments

[Debbie Sollis]

YESSSSSSSSSSSSS >>>>>>>>>> "Boundaries aren’t about controlling other people.

They’re about defining what your system accepts.

If you don’t implement boundary checks, the world will write your rules for you.

And it won’t optimize for your well-being"

[Larry Z.]

The “boundary checks” metaphor makes this idea especially clear: the problem isn’t simply being helpful—it’s allowing every request to reach execution without evaluating whether it belongs there.

A few highlights stood out:

• “Incoming request → accept → execute” perfectly captures how automatic yeses can bypass the most important question: should this request actually be processed?
• The API analogy is particularly effective. When every request receives a consistent “200 OK,” people naturally learn that the endpoint is available. Expectations can expand without anyone consciously deciding to take advantage.
• I like the nuance that exploitation doesn’t always require malicious intent. Sometimes people simply respond to the boundaries a system demonstrates—or fails to demonstrate.
• Priority corruption is one of the most significant hidden costs. Without filters, the loudest or most urgent external request can quietly become more important than your own priorities.
• The “accepted request ≠ aligned decision” distinction explains where resentment often begins. Saying yes externally while saying no internally creates a mismatch that eventually has to be paid for.
• Identity drift is another powerful point. If everything is accepted automatically, personal choice gradually disappears from the equation. You can become extremely responsive while becoming increasingly disconnected from what you actually want.
• The fix is refreshingly practical: evaluate the request, check capacity, allow yourself to reject it, control access, and stop treating immediate responses as mandatory.
• Most importantly, boundaries aren’t framed as punishment or control. They are input validation. They define what your system is designed to accept.

The line “If you don’t implement boundary checks, the world will write your rules for you” captures the larger lesson beautifully.

A healthy system doesn’t need to process every request that reaches it.

Sometimes integrity looks less like improving execution and more like deciding what never gets executed in the first place.

[Jean David]

Great essay thank you!

[Jean David]

Thank you for sharing this amazing writing here on DEV.to cheers!