Readers and editors need different doors
Your objectiveIdentify a management function that must not be publicly reachable.
Understand the idea.
A publication serves public content and also operates private tools. Editing, approvals and backups are not ordinary reader functions. Separating the public listener from the management listener reduces accidental exposure. The private listener still needs authentication and authorization; a different port is not a substitute for either.
A worked example.
An unauthenticated reader requests an editor API through the public hostname. The public application should not reveal the editor there. An authorized owner uses a separately protected management route. Both requests can reach the same underlying application code while encountering different boundaries.
Try the reasoning.
Classify homepage reading, article editing, quiz feedback, a database backup and a corrections submission as public or private. Explain any public write operation and the restrictions it needs.
Carry it into practice.
Test management paths through the public route and record the actual refusal, not just the intended configuration.
Read the reference: MDN · Content Security Policy ↗