Please Add References
When reviewers say please add references, they want foreign keys or ticket links on your changes. You fix this by linking your database tables and attaching ticket numbers to every run. Teams often handle this step inside code review tools before a database change goes live. Still, broad database roles still let users run unlinked commands on live servers. How the please add references rule works in team workflows A database needs clear links between tables to keep records accurate and clean.
Insecure Direct Object References (IDOR): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
When reviewers say please add references, they want foreign keys or ticket links on your changes. You fix this by linking your database tables and attaching ticket numbers to every run. Teams often handle this step inside code review tools before a database change goes live. Still, broad database roles still let users run unlinked commands on live servers.
How the please add references rule works in team workflows
A database needs clear links between tables to keep records accurate and clean. When you build a new table, you link its rows to existing primary keys. Reviewers write please add references on pull requests when those table links are missing. They also use this phrase when a script lacks a tracking ticket number.
In a standard setup, developers write schema changes in text files. They push these files to a shared code host for team review. Automated checks scan the files to see if foreign keys exist. The checks also look for a valid ticket number in the commit message. If both items are present, the team approves the file for release.
Database admins also set up native roles to control who can alter tables. One role allows a user to read rows from a table. Another role lets a user add foreign keys or change table rules. Teams assign these roles to user accounts or build servers. The database checks the role when the user logs in to run the script.
What native roles solve and where they fall short
Native roles and code reviews stop bad files from entering your main branch. Foreign keys stop apps from saving orphan rows in your tables. Ticket numbers in git logs help auditors see why a file changed. Together, these steps keep planned releases neat and easy to trace over time.
Still, this setup only checks files that go through your git workflow. It does not control what happens when an engineer logs in to fix a bug. Once a user logs in with an admin role, the database trusts every command. The native role decides who logs in, not what each command does in flight.
Insecure Direct Object References (IDOR): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
An engineer can run a quick update without linking a ticket or a reference. They can also query tables that hold sensitive data like emails or phone numbers. Native database logs often miss the ticket context for these live commands. Teams then struggle to tie live changes back to an approved support request.
How to enforce reference checks on live commands
To close this gap, teams must check every command right before it runs. Every live session should require a reason or a ticket reference before starting. When a peer reviews the single command, they can ask for missing details first. This step brings the same safety from code reviews into live database sessions.
Teams also need to protect private data during these live checks. Masking rules can rewrite matched fields like card numbers or national IDs in results. This way, users can fix broken table links without exposing private customer records. Every query and reference stays in one central log for future audits.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What does please add references mean in a database review?
It means your script needs foreign key links between tables or a tracking ticket number. Reviewers ask for this to keep data clean and trace every change.
Why do foreign key references matter for data safety?
Foreign keys make sure every child row points to a real parent row. They stop apps from leaving orphan records behind when a user deletes data.
How can teams link ticket references to live database queries?
Teams can require an approval step before a user runs a live command. The user enters the ticket number, and the system saves it with the query log.